Thanks for your contribution! I’ll give @regisd some time to review, but this looks good from my side. We should probably add nested include files afterwards in a separate commit.

Thank you for the review, @lsf37. I'm going to push a tweak to more exactly align the plugin's "guessing" regex matching with the LexScan.flex syntax for %include:

^ {WSP}* "%include" {WSP}+ .*  { includeFile(yytext().trim().substring(9).trim()); }

and to fix a typo.

(Would you like me to create an issue for considering nested includes for last-modifed checking?)

Thanks for the tweak, you're right that's closer to the expression in JFlex.

(Would you like me to create an issue for considering nested includes for last-modifed checking?)

Yes, please. I was going to do it right after the merge, but better to make sure I don't forget.

Looking through the code again, one question: is there a deeper reason for ignoring the include files in equals and hash? My instinct would be to add them here as well.

Looking through the code again, one question: is there a deeper reason for ignoring the include files in equals and hash? My instinct would be to add them here as well.

Oh my thinking was that the existing className and packageName were fundamental to the identity of ClassInfo as their natural key — and so part of the hash — but that the new tagalong data of includedFiles was not.

Oh my thinking was that the existing className and packageName were fundamental to the identity of ClassInfo as their natural key — and so part of the hash — but that the new tagalong data of includedFiles was not.

Got it. The class is currently only used to determine the output file name, but it makes sense the store the include file data here as well. I might rename it to SpecInfo later, but will merge as is for now.

@regisd is probably enjoying the holidays, so I'll merge now and we can address any changes later when he returns.

Thanks again for the contribution!

My pleasure! Thank you for the collaboration