Help mojo task is never up to date because descriptor tasks modifies outputs

[britter]

Status Quo

The maven tooling API tries to place the generated help mojo into the package that it thinks is the root package of the maven plugin project being build. Doing this is a three step process:

1. The help mojo java source is generated before classes are compiled and placed in the root package. It's possible to control this by setting helpPackageName on the PluginHelpGenerator (however we're currently not doing this).
2. After classes have been compiled the PluginDescriptorGenerator finds all mojos in the compiled classes. Based on this list it decides which package the help mojo should be put into.
3. The PluginDescriptorGenerator rewrites both the java source and the compiled class file of the help mojo implementation and moves the file into the target package.

Problem

The GenerateHelpMojoSource task defines an output directory that will contain the generated java source file. If the GenerateMavenPluginDescriptor runs afterwards it will delete that output and move it the new target location. GenerateHelpMojoSource is then out of date since outputs have been removed. On a subsequent build the situation becomes even worse: GenerateHelpMojoSource will run again and put a new help mojo source file into the root package. That will then be compiled. However the GenerateMavenPluginDescriptor is still up to date (probably due to underdeclared inputs, see https://github.com/britter/maven-plugin-development/blob/cc2f9622bcd43ca5e8a914eb4ded2c81634b0790/src/test/groovy/de/benediktritter/maven/plugin/development/UpToDateCheckingFuncTest.groovy). So this time the generated help mojo will not be moved which results in two help mojo classes ending up in the final output.

In summary: The core problem seems to be that the help mojo sources need to be generated before the target package can be found because that if detected based on compiled classes.

Ideas

The following ideas could be solutions to the problem:

• Require users to define the target package for the help mojo. This way there would be no need to rewrite the help mojo, thus fixing the problem. This solution would be less convenient than what the maven-plugin-plugin offers.
• Find the target package based on sources instead of based on compiled classes. Here we would implement our own heuristic for finding the target package based on source dirs rather than based on compiled classes. This would yield the same user experience (e.g. no need for users to declare the help mojo package) while being more complex to implement and potentially leading to different results than what the maven-plugin-plugin would generate.
• Separate the outputs of GenerateHelpMojoSources from the inputs of GenerateMavenPluginDescriptor with a copy. In this solution there would be a copy task that copies the outputs of the help mojo generation somewhere the GenerateMavenPluginDescriptor can consume and modify them. This doesn't really solve the problem. With this the GenerateHelpMojoSources would stay up to date but the copy task would never be up to date.