I believe the refresh should be AFTER the generation. It is to notify BuildContext about the changed/updated files.
Here's the docs on this that are available: https://wiki.eclipse.org/M2E_compatible_maven_plugins Also, have a look at the old code. It did work in v1.x. /Anders On Sat, May 2, 2015 at 1:39 PM, Lennart Jörelid <lennart.jore...@gmail.com> wrote: > All right; so if I understand correctly the m2e plugin uses information in > the BuildContext. > According to Sergei's example above, the BuildContext seems to want to > consume the whole output directory structure for its refresh method. > > Is the order of things to be: > > 1. if files are stale, then > 2. Refresh the buildContext, and then > 3. perform the execution of the tool > > In other words - is the buildContext.refresh call correctly placed below? > > // 3) Are generated files stale? > if (isReGenerationRequired()) { > > // Hack to support M2E > buildContext.refresh(getOutputDirectory()); > > if (performExecution()) { > > // As instructed by the performExecution() method, update > // the timestamp of the stale File. > updateStaleFileTimestamp(); > } else if (isInfoEnabled) { > log.info("Not updating staleFile timestamp as instructed."); > } > } else if (isInfoEnabled) { > log.info("No changes detected in schema or binding files - skipping JAXB > generation."); > } > > > 2015-04-29 23:35 GMT+02:00 Sergei Ivanov <sergei_iva...@mail.ru>: > >> Hi Lennart, >> >> I often curse the day when I out of good will decided to support M2E in >> my Maven plugin (I am a happy user of IntelliJ IDEA), but hopefully my >> experience helps you. >> Note that in M2E prior to 1.5 there was a major classloading issue, which >> broke quite a few plugins. >> >> I took a look at this: >> https://github.com/lennartj/jaxb2-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/jaxb2/AbstractXjcMojo.java >> ...and I see you have already got BuildContext declared as a @Component. >> All you need to do is use it. >> >> There are three parts to the implementation (in addition to providing >> lifecycle XML, which you've already done): >> >> 1. You build a list of input files and pass them to >> buildContext.hasDelta() one by one: >> >> /** >> * Checks if the injected build context has changes in any of the >> specified files. >> * >> * @param files files to be checked for changes. >> * @return {@code true}, if at least one file has changes; {@code >> false}, if no files have changes. >> */ >> protected boolean hasDelta(final Iterable<File> files) { >> for (final File file : files) { >> if (buildContext.hasDelta(file)) { >> return true; >> } >> } >> return false; >> } >> >> 2. You call this method inside mojo execute() before your own staleness >> detection check: >> >> if (!hasDelta(sourceFiles)) { >> getLog().info("Skipping compilation because build context has no >> changes."); >> buildContext.refresh(outputDirectory); >> return; >> } >> >> 3. You also need to call buildContext.refresh(outputDirectory) before >> exiting the mojo execute() method in all cases where execution succeeded >> (even if it was skipped due to other checks). >> >> Try it and see whether it works. >> >> Kind regards, >> -- >> Sergei Ivanov >> >> Среда, 29 апреля 2015, 20:17 +02:00 от Lennart Jörelid < >> lennart.jore...@gmail.com>: >> >> I am somewhat split about the concept of doing special development >> within a Maven plugin project to support any of the IDEs in the development >> community. >> >> An IDE claiming a tooling integration with Maven ought to be able to use >> the POM and the plugin descriptors out of the box. This seems certainly >> possible in the case of Netbeans and IntelliJ Idea without any special >> measures - so my gut reaction is that the Eclipse developers should fix >> Eclipse's Maven integration to actually work with only the Maven >> configuration instead of every plugin project developing special support >> for Eclipse. >> >> That being said, if the Eclipse integration is decently simple, we could >> certainly provide it. I would argue that such a solution should be testable >> in a standard IT within the plugin so the rest of the development community >> could know when the Eclipse integration works properly. Any Eclipse >> Developers out there are certainly encouraged to contribute, at least in >> letting me know how to test and verify that the j-m-p works with Eclipse. I >> added a screenshot of the Lifecycle mappings - as I can interpret them - >> from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of >> origin at least. >> >> >> 2015-04-29 10:11 GMT+02:00 Anders Hammar <and...@hammar.net >> <https://e.mail.ru/compose/?mailto=mailto%3aand...@hammar.net>>: >> >> As I earlier stated, after some investigation, there is some other change >> in the code that causes this to stop functioning. It worked in v1.x, but >> after your refactoring it doesn't any more. IMHO it's very unfortunate to >> just ignore such a key feature for anyone on Eclipse, especially as it >> worked in v1.x. >> >> /Anders >> >> On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid < >> lennart.jore...@gmail.com >> <https://e.mail.ru/compose/?mailto=mailto%3alennart.jore...@gmail.com>> >> wrote: >> >> The 2.0 release was cancelled, and since some features were added and >> some code was refactored in the plugin I felt it better to release version >> 2.1 instead. >> >> If someone who actually uses Eclipse feels like pinpointing the problem >> with why the m2e descriptor below does not work with the 2.x branch, I >> think all of us would be grateful. However, the goals are the same and >> annotated on the form >> >> @Mojo(name = "testSchemagen", >> defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES, >> requiresDependencyResolution = ResolutionScope.TEST, >> threadSafe = true) >> >> ... and the m2e descriptor seem to link to them correctly: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <lifecycleMappingMetadata> >> <pluginExecutions> >> <pluginExecution> >> <pluginExecutionFilter> >> <goals> >> <goal>xjc</goal> >> <goal>testXjc</goal> >> </goals> >> </pluginExecutionFilter> >> <action> >> <execute> >> <runOnIncremental>true</runOnIncremental> >> <runOnConfiguration>true</runOnConfiguration> >> </execute> >> </action> >> </pluginExecution> >> <pluginExecution> >> <pluginExecutionFilter> >> <goals> >> <goal>schemagen</goal> >> <goal>testSchemagen</goal> >> </goals> >> </pluginExecutionFilter> >> <action> >> <execute> >> <runOnIncremental>true</runOnIncremental> >> <runOnConfiguration>false</runOnConfiguration> >> </execute> >> </action> >> </pluginExecution> >> </pluginExecutions> >> </lifecycleMappingMetadata> >> >> >> 2015-04-29 8:44 GMT+02:00 Anders Hammar <and...@hammar.net >> <https://e.mail.ru/compose/?mailto=mailto%3aand...@hammar.net>>: >> >> What happened to v2.0 of the jaxb-m-p? Also, I really think we need to >> solve the m2e compat issue as that's a key thing for us on Eclipse (and it >> worked in v1.x). >> >> /Anders >> >> On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid < >> lennart.jore...@gmail.com >> <https://e.mail.ru/compose/?mailto=mailto%3alennart.jore...@gmail.com>> >> wrote: >> >> Hello all, >> >> It seems we are in the transition between Codehaus and MojoHaus/GitHub. >> I would believe that we should place each mojo in a separate Git repo - >> it makes sense, since they have different release cycles. >> >> However, if we do that, we need new settings for DistributionManagement, >> URL, IssueManagement and SCM in our mojo-parent (which really should >> migrate to the groupId "org.mojohaus", right?). I'm assuming that we should >> perform the releases from GitHub - but if we still can make releases from >> CodeHaus without changing too much, I would like to release the >> Jaxb2-Maven-Plugin version 2.1 first. >> >> -- >> >> -- >> +==============================+ >> | Bästa hälsningar, >> | [sw. "Best regards"] >> | >> | Lennart Jörelid >> | EAI Architect & Integrator >> | >> | jGuru Europe AB >> | Mölnlycke - Kista >> | >> | Email: l...@jguru.se >> <https://e.mail.ru/compose/?mailto=mailto%3...@jguru.se> >> | URL: www.jguru.se >> | Phone >> | (skype): jgurueurope >> | (intl): +46 708 507 603 >> | (domestic): 0708 - 507 603 >> +==============================+ >> >> >> >> >> >> -- >> >> -- >> +==============================+ >> | Bästa hälsningar, >> | [sw. "Best regards"] >> | >> | Lennart Jörelid >> | EAI Architect & Integrator >> | >> | jGuru Europe AB >> | Mölnlycke - Kista >> | >> | Email: l...@jguru.se >> <https://e.mail.ru/compose/?mailto=mailto%3...@jguru.se> >> | URL: www.jguru.se >> | Phone >> | (skype): jgurueurope >> | (intl): +46 708 507 603 >> | (domestic): 0708 - 507 603 >> +==============================+ >> >> >> >> >> >> -- >> >> -- >> +==============================+ >> | Bästa hälsningar, >> | [sw. "Best regards"] >> | >> | Lennart Jörelid >> | EAI Architect & Integrator >> | >> | jGuru Europe AB >> | Mölnlycke - Kista >> | >> | Email: l...@jguru.se >> <https://e.mail.ru/compose/?mailto=mailto%3...@jguru.se> >> | URL: www.jguru.se >> | Phone >> | (skype): jgurueurope >> | (intl): +46 708 507 603 >> | (domestic): 0708 - 507 603 >> +==============================+ >> >> >> > > > -- > > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ > >
