Re: multimodule aggregate javadoc jar
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
Could not able to calculate the build path.
Hi Team,
While creating a maven project in Eclipse (Oxygen 3A). we are getting the below
error ion pom.xml file.
[cid:image001.png@01D5DB4A.8DE781C0]
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.
Re: versioning by hashes to speedup multi-module build (a'la nix package manager)
Thomas Broyer, Enrico Olivelli, I consider the whole directory where the module's pom.xml resides, excluding the target/ dir, as the input, and the final module artifacts as the output. Even if some plugins allow sources outside the pom.xml's directory (out of curiosity, is it possible?), it is an acceptable restriction on project structure, IMO. The version hash approach I described may cause some redundant work. For example, if only dependencies changed, most often only re-testing is needed, re-compilation and re-packaging are not necessary (unless your dependency generates or instruments code at compilation time, or you package an uberjar or war, which includes dependency artifacts). But for stability better to compromise, accepting some redundant work, than go into such complexities as intermediate results of individual plugins, distinguishing test and prod sources, types of dependencies. Even the simplest hash versioning can potentially give significant speedups for large multi-module projects. I've spent this weekend trying to create a script for such version hashes. But haven't completed it (yet), due to various obstacles in maven behaviour (impossible to use property expression in the project/version element; the dependency:tree goal requires artifact of the current version to be present in the ~/.m2 folder, although it doesn't look into the artifact content, so it can even be a fake artifact). Maybe someday I'll have more progress. Best regards, - Anton - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven PMD Plugin 3.13.0 Released
The Maven team is pleased to announce the release of the Apache Maven PMD Plugin, version 3.13.0 A Maven plugin for the PMD toolkit, that produces a report on both code rule violations and detected copy and paste fragments, as well as being able to fail the build based on these metrics. https://maven.apache.org/plugins/maven-pmd-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-pmd-plugin 3.13.0 Release Notes - Apache Maven PMD Plugin - Version 3.13.0 Bug * [MPMD-295] Maven PMD Plugin fails on Java 13: Unsupported targetJdk value '13' * [MPMD-292] PMD Log is not always integrated into maven log * [MPMD-289] check: unable to find pmd.xml * [MPMD-288] NullPointerException when File.list() returns null Improvement * [MPMD-296] Copy ruleset files into a subdirectory of target * [MPMD-287] Add additional contribution information for GitHub * [MPMD-241] Document the version relationship between plugin and pmd New Feature * [MPMD-269] Display PMD version that is being used Task * [MPMD-293] Fix integration test builds on jenkins * [MPMD-291] Upgrade to PMD 6.21.0 * [MPMD-285] remove pluginTools version override for build (which block reproducible build...) * [MPMD-225] Create report even if no warnings have been found by default Enjoy, -The Maven team - 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 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
[ANN] Apache Maven Parent POMs 34 Released
The Apache Maven team is pleased to announce the release of the Maven Parent POMs Version 34. Maven Parent POMs include Maven Parent POM itself, but also Maven Plugins Parent POM, Maven Shared Components Parent POM, Maven Skins Parent POM and Maven Doxia Tools Parent POM. https://maven.apache.org/pom/maven/ You should specify the version in your project as parent like the following: org.apache.maven maven-parent 34 You can download the appropriate sources etc. from the download page: https://maven.apache.org/pom/maven/download.html Release Notes - Maven POMs - Version MAVEN-34 ** Bug * [MPOM-221] - All Links for Diff produce Forbidden * [MPOM-235] - Google Custom Search broken ** New Feature * [MPOM-223] - Introduce parent for extensions ** Improvement * [MPOM-216] - Update java minimum version to 7 * [MPOM-226] - Ignore .asf.yaml for license check in apache-rat-plugin * [MPOM-230] - Remove maven-report ** Task * [MPOM-217] - remove plexus javadoc taglet configuration ** Dependency upgrade * [MPOM-212] - upgrade plexus-component-metadata to 2.0.0 to get reproducible plexus/components.xml * [MPOM-234] - Upgrade apache-rat-plugin to 0.13 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-plugin: Cannot copy a directory
Hi, I think I found the reason. In the verify phase, I am executing errorprone, which uses the maven-compiler-plugin. Although I compile to target/classes-ep (instead of target/classes), somehow this seems to un-append artifacts. I think that the execution of an addition compilation should not un-append artifacts from the project build, should it? Ben Am Mo., 3. Feb. 2020 um 11:08 Uhr schrieb Benjamin Marwell : > > Hi all, > > since today my ear-plugin configuration does not work anymore and > stops with an exception. > > I pull in a dependency (type war) from another module in the same > reactor. I also pull the same dependency in again with a classifier > and another type to be used with the maven-assembly-plugin. > > Anyway, maven-ear-plugin does not try to pull in the war file, but the > target/classes directory instead: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on > project ear: Cannot copy a directory: > $HOME/svn/project/web/ui-v2/target/classes; Did you package/install > project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1] > > As I am using verify as goal. I checked that both the packages were > created in the referenced module. > > Any ideas where to look next? > > Thanks, > Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-ear-plugin: Cannot copy a directory
Hi all, since today my ear-plugin configuration does not work anymore and stops with an exception. I pull in a dependency (type war) from another module in the same reactor. I also pull the same dependency in again with a classifier and another type to be used with the maven-assembly-plugin. Anyway, maven-ear-plugin does not try to pull in the war file, but the target/classes directory instead: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on project ear: Cannot copy a directory: $HOME/svn/project/web/ui-v2/target/classes; Did you package/install project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1] As I am using verify as goal. I checked that both the packages were created in the referenced module. Any ideas where to look next? Thanks, Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven enforcer ensure javadoc attached
Hi Benjamin, thank you for your answer. But I don't see any option to check that the artifact are attached in the verify plugin. The problem is that the files can be present in the target folder but not attached if you have not run the goal in the same maven invocation as the one doing "install". I haven't tested, but maybe the solution is to always run the build-helper:attach-artifact goal which can be bound the the lifecycle so it can't be omitted during the release. It would do what I want if it fails when the files are not present. Thanks Jon On Mon, Feb 3, 2020 at 8:35 AM Benjamin Marwell wrote: > > Hi Jon, > > I think you could use the verifier-plugin for checking file existence. > > https://maven.apache.org/plugins/maven-verifier-plugin/verify-mojo.html > > Am So., 2. Feb. 2020 um 17:55 Uhr schrieb Jon Harper : > > > > Hi list, > > > > I would like to use maven-enforcer-plugin to ensure that javadocs are > > attached in release mode before installing. That's because I use > > $ mvn package javadoc:aggregate-jar deploy > > to build, so if someone forgets to call the aggregate-jar goal, the > > release will be missing the javadoc. > > > > I don't see any rule to enforce this (the closest I found is > > https://github.com/elastic/attached-artifact-enforcer which does the > > opposite, ensure that something is not attached). > > > > Is it possible to do what I want using the standard rules ? If not, > > would you consider to add new rules for this ? > > > > Thanks, > > Jon > > > > Note: I need to use javadoc:aggregate-jar on the command line and not > > part of the lifecycle because: > > - I want the aggregated javadoc to be attached to the root pom > > artifact, not some child "distribution"-like artifact > > - I want the aggregated javadoc to be created after the submodules > > have been built. > > > > - > > 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 > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
