Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
Good questions. First of all, this plugin is CI-agnostic, but it does require the project to exist in a `git` repository, whether that is in CI or on your machine. Check the github page I linked to for more instructions on how it determines what projects in a reactor are considered "changed" and need to be built versus which are not changed and will be omitted from the reactor. In every Maven build, every dependency is checked this way: 1. If it is a project in the reactor, use the artifact of that project. 2. Otherwise, if the artifact is in the local repo, is that artifact. 3. Last resort: Download from the remote repository. There are some other rules omitted above, e.g. when to download a fresh SNAPSHOT artifact based on your chosen snapshot policy, etc., but that's the gist of it: Maven will obtain the artifact if it is not present, no further configuration needed. E.g. let's say you have one project that names 2 other projects A and B as submodules, and A depends on B. If you run `mvn install -pl A` (NOT SURE about that syntax), then Maven will look for B.jar from your local repo, and resort to checking your remote repo (e.g. Maven Central) if it's not there. But if you omit the `-pl A` part, Maven will build B, then build A using B.jar. Essentially, the plugin I linked to determines the project list based on what has changed and what has not. Maven then decides whether to use B/target/B.jar, ~/.m2/repository/.../B.jar, or to look to Maven Central. HTH. On Tue, Feb 4, 2020 at 4:08 PM Anton Vodonosov wrote: > > > 04.02.2020, 23:32, "Jason Young" : > > > > Not what you're looking for, but maybe useful: We use one plugin that > will > > skip whole projects that have not changed WRT a given Git branch: > > https://github.com/vackosar/gitflow-incremental-builder. With careful > > configuration, this is an effective shortcut without sacrificing > > repeatability. > > How do you use it? I mean if you need to start full system, > (locally or deploying it to a qa server), > but the plugin has only built changed modules, > how do you download the rest? > > Do you use this plugin in CI? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --
Re: multimodule aggregate javadoc jar
Well almost, as far as I understand it's having aggregate-jar-no-fork and
binding it to a submodule that is after all other submodules in the build
plan (a "distribution"- like artifact, or an aggregator that is not the
parent). Unfortunately this changes the artifact in which clients look up
the javadocs (we used to put the aggregated javadocs in our parent pom) so
it's a bit confusing..
Thanks again for your time.
Jon
Le mar. 4 févr. 2020 à 22:10, Robert Scholte a
écrit :
> Well, so we're back to the missing javadoc:aggregate-jar-no-fork :)
>
>
> On 4-2-2020 19:38:43, Jon Harper wrote:
> Hi Robert, thanks again for your answers.
>
> I can't bind the javadoc:aggregate-jar goal to the package phase because
> goals with "@Mojo ( aggregator = true )" are only executed once (instead of
> once per module) if they are invoked from the command line.
>
> Cheers,
> Jon
>
> Le mar. 4 févr. 2020 à 18:48, Robert Scholte a
> écrit :
>
> > Hi Jon,
> >
> > it is not possible so start a lifecycle from the middle.
> > In case of 'mvn package javadoc:aggregate-jar install' you should bind
> > the javadoc:aggregate-jar to the package-phase, and now you can run 'mvn
> > install'.
> > If you don't want to run it all the time, consider putting the
> > javadoc-plugin in a profile and activate it when wished.
> >
> > You experience might improve if/when we implement MNG-5885
> >
> > thanks,
> > Robert
> >
> > https://issues.apache.org/jira/browse/MNG-5885
> > On 4-2-2020 08:58:18, Jon Harper 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 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 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: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail:
Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
04.02.2020, 23:32, "Jason Young" : > > Not what you're looking for, but maybe useful: We use one plugin that will > skip whole projects that have not changed WRT a given Git branch: > https://github.com/vackosar/gitflow-incremental-builder. With careful > configuration, this is an effective shortcut without sacrificing > repeatability. How do you use it? I mean if you need to start full system, (locally or deploying it to a qa server), but the plugin has only built changed modules, how do you download the rest? Do you use this plugin in CI? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multimodule aggregate javadoc jar
Well, so we're back to the missing javadoc:aggregate-jar-no-fork :)
On 4-2-2020 19:38:43, Jon Harper wrote:
Hi Robert, thanks again for your answers.
I can't bind the javadoc:aggregate-jar goal to the package phase because
goals with "@Mojo ( aggregator = true )" are only executed once (instead of
once per module) if they are invoked from the command line.
Cheers,
Jon
Le mar. 4 févr. 2020 à 18:48, Robert Scholte a
écrit :
> Hi Jon,
>
> it is not possible so start a lifecycle from the middle.
> In case of 'mvn package javadoc:aggregate-jar install' you should bind
> the javadoc:aggregate-jar to the package-phase, and now you can run 'mvn
> install'.
> If you don't want to run it all the time, consider putting the
> javadoc-plugin in a profile and activate it when wished.
>
> You experience might improve if/when we implement MNG-5885
>
> thanks,
> Robert
>
> https://issues.apache.org/jira/browse/MNG-5885
> On 4-2-2020 08:58:18, Jon Harper 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 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 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: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Could not able to calculate the build path.
I have seen similar issues if the maven plugin repository could not be
contacted.
On Tue, Feb 4, 2020 at 6:45 AM Roy, Arnab wrote:
> Hi Team,
>
>
>
> While creating a maven project in Eclipse (Oxygen 3A). we are getting the
> below error ion pom.xml file.
>
>
>
>
>
> With below error description:
>
>
>
> Errors occurred during the build.
>
> Errors running builder 'Maven Project Builder' on project Name.
>
> Could not calculate build plan: Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-resources-plugin:jar:2.6
>
> Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-resources-plugin:jar:2.6
>
> Could not calculate build plan: Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-resources-plugin:jar:2.6
>
> Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-resources-plugin:jar:2.6
>
>
>
>
>
> Could you please help us solving this issue.
>
>
>
> Thanks and Regards,
>
> Arnab Roy
> --
> This email (including any attachments) is intended for the designated
> recipient(s) only, and may be confidential, non-public, proprietary, and/or
> protected by the attorney-client or other privilege. Unauthorized reading,
> distribution, copying or other use of this communication is prohibited and
> may be unlawful. Receipt by anyone other than the intended recipient(s)
> should not be deemed a waiver of any privilege or protection. If you are
> not the intended recipient or if you believe that you have received this
> email in error, please notify the sender immediately and delete all copies
> from your computer system without reading, saving, printing, forwarding or
> using it in any manner. Although it has been checked for viruses and other
> malicious software ("malware"), we do not warrant, represent or guarantee
> in any way that this communication is free of malware or potentially
> damaging defects. All liability for any actual or alleged loss, damage, or
> injury arising out of or resulting in any way from the receipt, opening or
> use of this email is expressly disclaimed.
>
--
I like: Like Like - The likeliest place on the web
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
It seems Maven itself never omits re-doing anything except for downloading artifacts from a remote repository. The command you give to Maven and the configuration of your projects dictates what it will do, no matter what happened in the previous build. You _can_ omit projects in a multi-module project if by manually specifying what projects to run: https://blog.sonatype.com/2009/10/maven-tips-and-tricks-advanced-reactor-options/ Not what you're looking for, but maybe useful: We use one plugin that will skip whole projects that have not changed WRT a given Git branch: https://github.com/vackosar/gitflow-incremental-builder. With careful configuration, this is an effective shortcut without sacrificing repeatability. Gradle advertises as a feature that it will not rebuild if rebuilding is not required, or something to that effect. I assume some configuration required sometimes. On Tue, Feb 4, 2020 at 1:57 PM Anton Vodonosov wrote: > Ha, only after completing the script (even though a slow one) > I discovered that maven rebuilds modules even if > an artifact of the same version already exists in artifact > repository. > > I hoped maven, in case a non -SNAPSHOT artifact > found in an artifact repository will just use it > and won't build the same version of a module again. > > Is there a way to tell maven to do so? > > Best regards, > - Anton > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --
Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
Ha, only after completing the script (even though a slow one) I discovered that maven rebuilds modules even if an artifact of the same version already exists in artifact repository. I hoped maven, in case a non -SNAPSHOT artifact found in an artifact repository will just use it and won't build the same version of a module again. Is there a way to tell maven to do so? Best regards, - Anton - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multimodule aggregate javadoc jar
Hi Robert, thanks again for your answers.
I can't bind the javadoc:aggregate-jar goal to the package phase because
goals with "@Mojo ( aggregator = true )" are only executed once (instead of
once per module) if they are invoked from the command line.
Cheers,
Jon
Le mar. 4 févr. 2020 à 18:48, Robert Scholte a
écrit :
> Hi Jon,
>
> it is not possible so start a lifecycle from the middle.
> In case of 'mvn package javadoc:aggregate-jar install' you should bind
> the javadoc:aggregate-jar to the package-phase, and now you can run 'mvn
> install'.
> If you don't want to run it all the time, consider putting the
> javadoc-plugin in a profile and activate it when wished.
>
> You experience might improve if/when we implement MNG-5885
>
> thanks,
> Robert
>
> https://issues.apache.org/jira/browse/MNG-5885
> On 4-2-2020 08:58:18, Jon Harper 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 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 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: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: multimodule aggregate javadoc jar
Looks like a bug, please create a ticket for it at
https://issues.apache.org/jira/browse/MNG
thanks,
Robert
On 4-2-2020 09:20:12, Jon Harper wrote:
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 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 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 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: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: multimodule aggregate javadoc jar
Hi Jon,
it is not possible so start a lifecycle from the middle.
In case of 'mvn package javadoc:aggregate-jar install' you should bind the
javadoc:aggregate-jar to the package-phase, and now you can run 'mvn install'.
If you don't want to run it all the time, consider putting the javadoc-plugin
in a profile and activate it when wished.
You experience might improve if/when we implement MNG-5885
thanks,
Robert
https://issues.apache.org/jira/browse/MNG-5885
On 4-2-2020 08:58:18, Jon Harper 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 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 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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: multimodule aggregate javadoc jar
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 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 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 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: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
