[m2e-users] Using M2E metadata in Joda-Beans maven plugin

[Stephen Colebourne <scolebourne@xxxxxxxx>]

Hi all,
I've recently added M2E metadata to the Joda-Beans maven plugin to
better support Eclipse:
https://github.com/JodaOrg/joda-beans-maven-plugin/commit/1fbd8eadc42c1bec70f2f5079e027289851a51ca

Joda-Beans is a source code generator that takes a developer edited
.java source file and adds autogenerated code (to the same source
file). For example:
https://github.com/JodaOrg/joda-beans/blob/v1.4/src/test/java/org/joda/beans/gen/UserAccount.java#L34
I believe that Joda-Beans editing the original .java file (rather than
creating a new .java file) is unusual in the realm of maven-plugins
and m2e.

The first change to include the m2e metadata xml file in
joda-beans-maven-plugin (rather than each end-user pom.xml) worked
well - good job!

The second change was to use the execute/runOnIncremental=true mode to
get Eclipse to dynamically regenerate the code when the file is
edited. Adding basic use of BuildContext (refresh and addMessage)
worked OK, but things got more complicated and my final solution feels
hacky.

One minor problem was that I end up with two errors in Eclipse when
there is a problem. One error marker appears in the pom.xml file from
the thrown MojoFailureException and one error marker appears in the
source file from buildContext.addMessage() (as expected/desired). Is
there any way to avoid the MojoFailureException adding an error
marker?
https://github.com/JodaOrg/joda-beans-maven-plugin/commit/1fbd8eadc42c1bec70f2f5079e027289851a51ca#diff-7b40ac75b969c88992c998201847ce0aR371

The main problem was that calling buildContext.refresh() on the
updated .java source file was insufficient to properly refresh the
file. Calling buildContext.refresh() on the updated .java file caused
Eclipse to reload the .java source file and correctly update some
internal state. However, it did not trigger a full recompilation of
that source file, which resulted in error markers (I think the source
file was in some way partially recompiled). Those error markers could
be solved by forcing a rebuild of the source file (such as adding and
deleting a space in the .java source file, or using the Project/Clean
menu in Eclipse).

To solve this, I found a hacky solution. As well as calling
buildContext.refresh() on the updated .java source file, I also delete
the matching compiled .class file from target/classes. This results in
what appears to be a "double refresh" in Eclipse - first the
previously observed buildContext.refresh() error markers appear, and
then Eclipse recompiles the file (because the .class file is missing)
and the error markers disappear. Note that I tried calling
buildContext.refresh() on the .class file but that had no effect.
https://github.com/JodaOrg/joda-beans-maven-plugin/commit/1fbd8eadc42c1bec70f2f5079e027289851a51ca#diff-7b40ac75b969c88992c998201847ce0aR219

While hacky, the plugin does now work well. Eclipse can now be setup
such that any edit to a Joda-Bean .java source file causes the file to
be regenerated and recompiled, without needing to learn how to write
an Eclipse plugin.

My main question is whether anyone has any suggestions on how to
improve this hack? Why is buildContext.refresh() not enough to trigger
a full recompilation of the .java source file?

thanks
Stephen