Also a "funny" thing is that running an aggregator mojo between 2 phases in a multimodule project shows the wrong build step numbers: (In this example I generated a quick project setup with mvn archetype: a parent pom with 2 children)
# javadoc:jar is *not* an aggregator mojo, this looks correct $ mvn package javadoc:jar install [INFO] Building my-aggrega 1.0-SNAPSHOT [1/3] [INFO] Building my-app3 1.0-SNAPSHOT [2/3] [INFO] Building my-app2 1.0-SNAPSHOT [3/3] $ mvn package javadoc:aggregate-jar install [INFO] Building my-aggrega 1.0-SNAPSHOT [1/3] [INFO] Building my-app3 1.0-SNAPSHOT [2/3] [INFO] Building my-app2 1.0-SNAPSHOT [3/3] [INFO] Building my-aggrega 1.0-SNAPSHOT [4/3] [INFO] Building my-aggrega 1.0-SNAPSHOT [5/3] [INFO] Building my-app3 1.0-SNAPSHOT [6/3] [INFO] Building my-app2 1.0-SNAPSHOT [7/3] Jon On Tue, Feb 4, 2020 at 8:58 AM Jon Harper <[email protected]> wrote: > > Hi Robert, > thanks for you reply. I'll keep an eye out for these improvements. > > Another obstacle to my use case is that when running > $ mvn package javadoc:aggregate-jar install > the install phase doesn't continue where package finished, instead it > starts over. > > Is there a way to tell maven to run the lifecycle only once and > continue from the previous phase ? > > Note: > The same thing happens when running > $ mvn package install > or even > $ mvn package package > everything is done twice. > > thanks in advance, > Jon > > On Mon, Feb 3, 2020 at 8:12 PM Robert Scholte <[email protected]> wrote: > > > > Hi Jon, > > > > it is bothering me for a while that Maven is not yet capable to see that a > > fork is not required (in most cases) when it is executed as part of a > > lifecycle. > > Introducing x-no-fork goals is a fast workaround, but it is probably time > > to do this properly. > > > > Also plugins should be improved to see if they should do their action, e.g.: > > Consider using the following flag in for the java compiler: > > > > -Xpkginfo:{always,legacy,nonempty} Specify handling of package-info files > > > > Maybe this will already improve your buildtime. > > > > thanks, > > Robert > > > > On 2-2-2020 17:56:15, Jon Harper <[email protected]> wrote: > > Hi list, > > > > I would like to package a multimodule project (jar of each submodule) > > and then create one aggregated javadoc jar attached to root pom. > > The best solution I came up with is using the following command line > > > > $ mvn package javadoc:aggregate-jar > > > > It uses the fact that aggregate-jar is declared "@Mojo ( aggregator = > > true )", so when the goal is explicitly called on the command line it > > executes only once on the root pom. (if the goal is bound to a phase > > of the lifecycle of the root pom, it will execute before the children > > which I don't want) > > > > One downside of this approach is that aggregate-jar forks the > > lifecycle and so everything gets recompiled (which takes a long time > > if you have many modules, or if you use features that prevent avoiding > > recompiling, like having a package-info.java or using > > maven-templating-plugin to insert build timestamps in your sources) > > > > It seems like adding a javadoc:aggregate-jar-no-fork would solve the > > problem. > > > > Is my understanding correct, and can we add the aggregate-jar-no-fork > > goal ? Or what is everyone doing to generate aggregated javadocs > > without recompiling everything > > > > Thanks, > > Jon > > > > PS: another downside is that you must not forget to add the explicit > > goal on the command line, but I can't see a solution for that, except > > for the proposed lifecycle redesign with pre and post phases, which we > > will get in the far future as far as I understand. > > > > PS2: adding javadoc:aggregate-jar-no-fork would also be useful for > > people who generate their aggregated javadoc on a "distribution" > > submodule which has dependencies to everything instead of the root > > pom. Currently they can make it work by using aggregate-no-fork and > > then maven-jar-plugin but it's a bit complicated. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
