[ANN] Apache Maven Shade Plugin 3.5.3 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Shade Plugin, version 3.5.3

This plugin provides the capability to package the artifact in an uber-jar, 
including its dependencies and to shade - i.e. rename - the packages of some 
of the dependencies.

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.5.3


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes - Maven Shade Plugin - Version 3.5.3

** Bug
* [MSHADE-471] - still timestamp issues with timezones (DST)

** Task
* [MSHADE-472] - upgrade parent POM

** Dependency upgrade
* [MSHADE-470] - Upgrade ASM to 9.7 (Java 23)

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Plugin Tools 3.12.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Plugin Tools, version 3.12.0

The Maven Plugin Tools contains the necessary tools to generate rebarbative 
content like descriptor, help and documentation.

https://maven.apache.org/plugins-tools/index.html

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-plugin-plugin
3.12.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugin-tools/download.html

Release Notes - Maven Plugin Tools - Version 3.12.0

** Improvement
* [MPLUGIN-510] - update plugin system requirements history structure
* [MPLUGIN-511] - create and share tooling to detect plugin prerequisites 
history
* [MPLUGIN-514] - switch dependency schema from png + imagemap to svg, and 
update

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Source Plugin 3.3.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Source Plugin, version 3.3.1

The Source Plugin creates a jar archive of the source files of the current
project.

https://maven.apache.org/plugins/maven-source-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-source-plugin
  3.3.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-source-plugin/download.cgi

Release Notes - Maven Source Plugin - Version 3.3.1

** Bug
* [MSOURCES-139] - Typo in exception

** Improvement
* [MSOURCES-137] - umask makes artifacts generated by maven-source-plugin 
not easy to reproduce

** Dependency upgrade
* [MSOURCES-142] - Upgrade plexus-archiver to 4.8.0

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Artifact Plugin 3.5.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Artifact Plugin, version 3.5.1

This plugin is used for Reproducible Builds tasks about artifacts.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.5.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-artifact-plugin/download.cgi

Release Notes - Maven Artifact Plugin - Version 3.5.1

** Bug
* [MARTIFACT-54] - In multi-module projects check-buildplan fails on 
project.build.outputTimestamp

** Improvement
* [MARTIFACT-52] - add moduleinfo.skipModules property to skipModules 
parameter
* [MARTIFACT-53] - improve message when outputTimestamp not defined in 
reactor: WARN only
* [MARTIFACT-56] - Upgrade maven-plugin parent to 41

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: [VOTE] Require Java 17 for Maven 4

[Hervé Boutemy]

+1

I would just like to get help on enablers

Regards,

Hervé

Le mercredi 28 février 2024, 08:30:07 CET Benjamin Marwell a écrit :
> Hi Maven Devs/Users/Committers and PMC members!
> 
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
> 
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
> 
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
> 
> PR: https://github.com/apache/maven/pull/1430
> 
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
> 
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
> 
> ---
> 
> Vote open for 72 hours:
> 
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
> 
> ---
> 
> - Ben
> 
> [1*]: https://www.apache.org/foundation/voting.html
> 
> -
> 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

[ANN] Apache Maven Shade Plugin 3.5.2 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Shade Plugin, version 3.5.2

This plugin provides the capability to package the artifact in an uber-jar, 
including its dependencies and to shade - i.e. rename - the packages of some 
of the dependencies.

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.5.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes - Maven Shade Plugin - Version 3.5.2

** Bug
* [MSHADE-420] - Reproducible Builds timestamp issue in some cases
* [MSHADE-462] - 3.5.1 not compatible with 3.4.1: The version cannot be 
empty
* [MSHADE-467] - Dependency-reduced POM with missing exclusions in 
concurrent build
* [MSHADE-469] - Cannot generate a jar since switching from 3.4.1 to 3.5.x

** Improvement
* [MSHADE-468] -  add plugin system requirements history section

** Dependency upgrade
* [MSHADE-463] - Bump asmVersion from 9.5 to 9.6
* [MSHADE-464] - Maven 3.6.3 as minimum requirements

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: Generate soft-links as part of site build

[Hervé Boutemy]

here is the explanation:
https://maven.apache.org/developers/website/index.html

for example every plugin in https://maven.apache.org/plugins/index.html is a 
symlink:
https://svn.apache.org/viewvc/maven/website/content/plugins/

Le jeudi 30 novembre 2023, 22:51:04 CET sebb a écrit :
> Thanks very much, that looks very promising.
> 
> On Thu, 30 Nov 2023 at 19:26, Michael Osipov  wrote:
> > On 2023/11/28 17:35:40 sebb wrote:
> > > Is it possible to generate soft-links as part of a site build?
> > > 
> > > I tried adding them to the resources/ folder, but they were ignored.
> > 
> > While I haven't tried explicitly, what about
> > https://github.com/apache/maven-site/blob/c9e53bb488964ec2236688db41f9ddc
> > 90e642702/pom.xml#L246-L264?
> > 
> > -
> > 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

Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Hervé Boutemy]

improvement proposed: review appreciated
https://github.com/apache/maven-reporting-impl/pull/24

Le mercredi 4 octobre 2023, 08:30:04 CEST Hervé Boutemy a écrit :
> Hi Xander,
> 
> Sorry, I lost track, having a look now.
> 
> When I see that you are implementing Mojo's "execute()" [1] while using
> maven-reporting-impl, you are in fact defeating the objective of
> maven-reporting-impl: do that for you.
> 
> maven-reporting-impl would probably need better documentation, I need help,
> but the IT [2] tries to show how to write such reporting code that can be
> run both as goal and a maven-site's report
> 
> And if you want to see how it does the job, you can look at
> maven-reporting-impl AbstractMavenReport implementation of execute() [3]:
> yes, that implementation changed, and now I remember I had to update it
> because of the NPE that it could cause. You must not rewrite this code.
> 
> HTH
> 
> Hervé
> 
> 
> [1]
> https://github.com/dev-aspectj/aspectj-maven-plugin/blob/main/src/main/java
> /org/codehaus/mojo/aspectj/AjcReportMojo.java#L210
> 
> [2]
> https://github.com/apache/maven-reporting-impl/tree/master/src/it/setup-rep
> orting-plugin/src/main/java/org/apache/maven/reporting/its/custom
> 
> [3]
> https://github.com/apache/maven-reporting-impl/blob/master/src/main/java/or
> g/apache/maven/reporting/AbstractMavenReport.java#L187
> Le mercredi 4 octobre 2023, 04:05:58 CEST Alexander Kriegisch a écrit :
> > Hello Hervé.
> > 
> > Did the reproducer help you in any way?
> > 
> > Regards
> > 
> > > Hello Hervé.
> > > 
> > >>> I tried to upgrade those
> > >>> dependencies to the most recent Doxia and Sitetools versions.
> > >> 
> > >> by "most recent", do you mean most recent from 1.x or 2.0.0-M*?
> > > 
> > > I mean 2.0.0-M*. Actually, the project works nicely and I would have
> > > ignored the Dependabot suggestions, but all those Maven warnings about
> > > outdated or EOL components made me start upgrading them. I was under the
> > > impression that Doxia milestones are just as stable and production-ready
> > > as Surefire ones, so I did not think much and gaven them a go.
> > > 
> > >> 1.x should not cause issues
> > >> 
> > >> 2.0.0-M*, as expected from the version number, is more risky and not
> > >> yet
> > >> fully
> > >> 
> > >> stable
> > > 
> > > Then maybe it is better to revert to 1.x and let users live live with
> > > the
> > > Plexus warnings for a little longer.
> > > 
> > >> Such reporting plugin coding has so many ways to be done that sharing a
> > >> reproducer is the easiest way to have concrete view on what is
> > >> happening,
> > >> particularly if you're going to 2.0.0-M*
> > > 
> > > Sure, it is about https://github.com/dev-aspectj/aspectj-maven-plugin.
> > > 
> > > On the main branch,
> > > 
> > >   -- an older commit like 93110452 shows the (stable) situation before I
> > >   
> > >  started various and sundry plugins and dependencies,
> > >   
> > >   -- second-latest commit 7b8706a7 - see also build
> > >   
> > >  https://github.com/dev-aspectj/aspectj-maven-plugin/actions/runs/62
> > >  30
> > >  950536
> > >  - shows an intermediate step in which the plugin's reporting
> > >  goalfails in integration tests,
> > >   
> > >   -- latest commit 1a819a4e stabilises the integration tests, but is a
> > >   
> > >  hacky work-in-progress commit that needs to be cleaned up. You
> > >  asked for a reproducer, so I pushed the commit.
> > > 
> > > You can build the plugin quickly, if you deactivate the
> > > 'integration-test' profile. In order to reproduce the problem, run
> > > something like
> > > 
> > > mvn -Dinvoker.test=CreateReport verify -P integration-test
> > > 
> > > on the lat6est commit, but locally revert this change in
> > > AjcReportMojo.java:
> > > https://github.com/dev-aspectj/aspectj-maven-plugin/commit/1a819a4e0b2c3
> > > c
> > > d34797c3122488ea5833cf9fd5#diff-64f2431d9507f2996b65ccf8f9a4e202923d456e
> > > 31
> > > 579f3809ef4d648509b62e
> > > 
> > > Regards
> > > --
> > > Xander
> > > https://scrum-master.de
> > > 
> > >> Le jeudi 7 septembre 2023, 04:35:29 CEST Alexander Kriegisch a écrit 

Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Hervé Boutemy]

Hi Xander,

Sorry, I lost track, having a look now.

When I see that you are implementing Mojo's "execute()" [1] while using 
maven-reporting-impl, you are in fact defeating the objective of 
maven-reporting-impl: do that for you.

maven-reporting-impl would probably need better documentation, I need help, but 
the IT [2] tries to show how to write such reporting code that can be run both 
as goal and a maven-site's report

And if you want to see how it does the job, you can look at 
maven-reporting-impl AbstractMavenReport implementation of execute() [3]: yes, 
that implementation changed, and now I remember I had to update it because of 
the NPE that it could cause. You must not rewrite this code.

HTH

Hervé


[1] 
https://github.com/dev-aspectj/aspectj-maven-plugin/blob/main/src/main/java/org/codehaus/mojo/aspectj/AjcReportMojo.java#L210

[2] 
https://github.com/apache/maven-reporting-impl/tree/master/src/it/setup-reporting-plugin/src/main/java/org/apache/maven/reporting/its/custom

[3] 
https://github.com/apache/maven-reporting-impl/blob/master/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L187

Le mercredi 4 octobre 2023, 04:05:58 CEST Alexander Kriegisch a écrit :
> Hello Hervé.
> 
> Did the reproducer help you in any way?
> 
> Regards
> 
> > Hello Hervé.
> > 
> >>> I tried to upgrade those
> >>> dependencies to the most recent Doxia and Sitetools versions.
> >> 
> >> by "most recent", do you mean most recent from 1.x or 2.0.0-M*?
> > 
> > I mean 2.0.0-M*. Actually, the project works nicely and I would have
> > ignored the Dependabot suggestions, but all those Maven warnings about
> > outdated or EOL components made me start upgrading them. I was under the
> > impression that Doxia milestones are just as stable and production-ready
> > as Surefire ones, so I did not think much and gaven them a go.
> > 
> >> 1.x should not cause issues
> >> 
> >> 2.0.0-M*, as expected from the version number, is more risky and not yet
> >> fully
> >> 
> >> stable
> > 
> > Then maybe it is better to revert to 1.x and let users live live with the
> > Plexus warnings for a little longer.
> > 
> >> Such reporting plugin coding has so many ways to be done that sharing a
> >> reproducer is the easiest way to have concrete view on what is happening,
> >> particularly if you're going to 2.0.0-M*
> > 
> > Sure, it is about https://github.com/dev-aspectj/aspectj-maven-plugin.
> > 
> > On the main branch,
> > 
> >   -- an older commit like 93110452 shows the (stable) situation before I
> >   
> >  started various and sundry plugins and dependencies,
> >   
> >   -- second-latest commit 7b8706a7 - see also build
> >   
> >  https://github.com/dev-aspectj/aspectj-maven-plugin/actions/runs/6230
> >  950536
> >  - shows an intermediate step in which the plugin's reporting
> >  goalfails in integration tests,
> >   
> >   -- latest commit 1a819a4e stabilises the integration tests, but is a
> >   
> >  hacky work-in-progress commit that needs to be cleaned up. You
> >  asked for a reproducer, so I pushed the commit.
> > 
> > You can build the plugin quickly, if you deactivate the
> > 'integration-test' profile. In order to reproduce the problem, run
> > something like
> > 
> > mvn -Dinvoker.test=CreateReport verify -P integration-test
> > 
> > on the lat6est commit, but locally revert this change in
> > AjcReportMojo.java:
> > https://github.com/dev-aspectj/aspectj-maven-plugin/commit/1a819a4e0b2c3c
> > d34797c3122488ea5833cf9fd5#diff-64f2431d9507f2996b65ccf8f9a4e202923d456e31
> > 579f3809ef4d648509b62e
> > 
> > Regards
> > --
> > Xander
> > https://scrum-master.de
> > 
> >> Le jeudi 7 septembre 2023, 04:35:29 CEST Alexander Kriegisch a écrit :
> >>> Hello Maven community.
> >>> 
> >>> In a Maven plugin using old 1.x Doxia and Sitetool versions, I am
> >>> getting
> >>> warnings because those again use an EOL Plexus component. The details
> >>> are
> >>> not so important, the important part is that I tried to upgrade those
> >>> dependencies to the most recent Doxia and Sitetools versions.
> >>> 
> >>> One class in the plugin extends
> >>> org.apache.maven.reporting.AbstractMavenReport. It implements an
> >>> executeReport(Locale) method, which so far was fine. But now, it also
> >>> inherits execute() from the abstract parent class. The latter method is
> >>> always called when using the reporting goal for my plugin. The result is
> >>> an
> >>> 
> >>> error like this:
> >>>   Caused by: java.lang.NullPointerException: Cannot invoke
> >>> 
> >>> "org.apache.maven.doxia.tools.SiteTool.getSiteLocales(String)" because
> >>> "this.siteTool" is null at
> >>> org.apache.maven.reporting.AbstractMavenReport.getLocale
> >>> (AbstractMavenReport.java:400) at
> >>> org.apache.maven.reporting.AbstractMavenReport.reportToMarkup
> >>> (AbstractMavenReport.java:212) at
> >>> org.apache.maven.reporting.AbstractMavenReport.execute
> >>> (AbstractMavenReport.java:189)
> >>> 
> >>> I see that 

[ANN] Apache Maven Artifact Plugin 3.5.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Artifact Plugin, version 3.5.0

This plugin is used for Reproducible Builds tasks about artifacts.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.5.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-artifact-plugin/download.cgi

Release Notes - Maven Artifact Plugin - Version 3.5.0

** Bug
* [MARTIFACT-33] - confusion in aggregate comparison when 2 modules have 
same artifactId

** New Feature
* [MARTIFACT-34] - detect ignored modules when nexus-staging-maven-plugin 
skipNexusStagingDeployMojo=true
* [MARTIFACT-47] - add compare.fail parameter (true by default) to be able 
to not fail the build

** Improvement
* [MARTIFACT-48] - rework exclude parameter
* [MARTIFACT-49] - Add support for Maven 4 build vs consumer pom
* [MARTIFACT-50] - add skipModules parameter

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: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Hervé Boutemy]

> I tried to upgrade those
> dependencies to the most recent Doxia and Sitetools versions.
by "most recent", do you mean most recent from 1.x or 2.0.0-M*?

1.x should not cause issues
2.0.0-M*, as expected from the version number, is more risky and not yet fully 
stable

Such reporting plugin coding has so many ways to be done that sharing a 
reproducer is the easiest way to have concrete view on what is happening, 
particularly if you're going to 2.0.0-M*

Regards,

Hervé

Le jeudi 7 septembre 2023, 04:35:29 CEST Alexander Kriegisch a écrit :
> Hello Maven community.
> 
> In a Maven plugin using old 1.x Doxia and Sitetool versions, I am getting
> warnings because those again use an EOL Plexus component. The details are
> not so important, the important part is that I tried to upgrade those
> dependencies to the most recent Doxia and Sitetools versions.
> 
> One class in the plugin extends
> org.apache.maven.reporting.AbstractMavenReport. It implements an
> executeReport(Locale) method, which so far was fine. But now, it also
> inherits execute() from the abstract parent class. The latter method is
> always called when using the reporting goal for my plugin. The result is an
> error like this:
> 
>   Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.maven.doxia.tools.SiteTool.getSiteLocales(String)" because
> "this.siteTool" is null at
> org.apache.maven.reporting.AbstractMavenReport.getLocale
> (AbstractMavenReport.java:400) at
> org.apache.maven.reporting.AbstractMavenReport.reportToMarkup
> (AbstractMavenReport.java:212) at
> org.apache.maven.reporting.AbstractMavenReport.execute
> (AbstractMavenReport.java:189)
> 
> I see that AbstractMavenReport defines the 'siteTool' field as follows:
> 
>   @Component
>   protected SiteTool siteTool;
> 
> I am wondering why that field is null. Should it not be populated
> automatically by dependency injection? I have a dirty workaround for this
> problem:
> 
>   @Override
>   public void execute() throws MojoExecutionException {
>   //super.execute();
>   try {
>   executeReport(Locale.getDefault());
>   }
>   catch (MavenReportException e) {
>   throw new MojoExecutionException(e);
>   }
>   }
> 
> This way, 'siteTool' is not used and method SiteTool.getSiteLocales(String)
> never called. But I guess, that is not a good solution to the problem. How
> are plugin implementors meant to deal with this situation? Or is this some
> kind of bug? I am unsure how to proceed. I am by no means a Maven plugin
> buff and merely helping to keep an existing plugin alive. I would be
> grateful for hints.
> 
> Regards





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven wrapper and sha256

[Hervé Boutemy]

>(since we don't know if the file is the right one).
for that purpose, you should check the pgp signature against Apache Maven 
developers KEYS, which can't be tricked by anybody, unlike checksums hosted 
anywhere.

FTR, instructions "In order to guard against corrupted downloads/
installations" are there:
https://maven.apache.org/download.cgi#files

Regards,

Hervé

Le jeudi 14 septembre 2023, 18:25:01 CEST Alexis Tual a écrit :
> Hi Nils, thanks for your quick response!
> 
> Yeah, calculating the checksum yourself kind of defeats the purpose (since
> we don't know if the file is the right one).
> Although that's true I could use another available checksum, verify it and
> then calculate the sha256.
> But it would add complexity to the automated workflow I'm working on. I'll
> fill a request ticket then.
> 
> Thanks!
> 
> Le jeu. 14 sept. 2023 à 18:17, Nils Breunese  a écrit :
> > Hi Alexis,
> > 
> > I don’t know if SHA-256 hashes are published anywhere, but after verifying
> > the other hashes that are published on Maven Central, you could calculate
> > the SHA-256 hashes yourself. (I’m sorry if I’m being Captain Obvious
> > here.)
> > 
> > For the Maven distribution:
> > 
> > ❯ shasum -a 256
> > ~/.m2/wrapper/dists/apache-maven-3.9.4-bin/*/apache-maven-3.9.4-bin.zip |
> > awk ‘{ print $1 }'
> > e896b60329a71b719d77bb4388b251a50aebcd73c62f69d510c858ce360afe0f
> > 
> > And for the Maven Wrapper JAR in your project:
> > 
> > ❯ shasum -a 256 .mvn/wrapper/maven-wrapper.jar | awk '{ print $1 }'
> > e63a53cfb9c4d291ebe3c2b0edacb7622bbc480326beaa5a0456e412f52f066a
> > 
> > But yes, I agree it would be nicer if Maven Central and/or release notes
> > would contain the SHA-256 hashes for use with this feature. Maybe open a
> > request ticket for that (
> > https://issues.apache.org/jira/secure/CreateIssue!default.jspa)?
> > 
> > Nils.
> > 
> > > Op 14 sep. 2023, om 16:29 heeft Alexis Tual  het
> > 
> > volgende geschreven:
> > > Hi,
> > > 
> > > I noticed the Maven wrapper supports setting the sha256 for both the
> > 
> > > distributions and the wrapper jar:
> > https://maven.apache.org/wrapper/#checksum-verification-of-downloaded-bina
> > ries> 
> > > .
> > > However I could not find those checksums in
> > > https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/ nor
> > 
> > https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrappe
> > r
> > .
> > 
> > > Where are they located?
> > > 
> > > Thanks for your help!
> > > 
> > > --
> > > 
> > > Alexis Tual





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven 3.3.9 allows overriding readonly parameters for plugins

[Hervé Boutemy]

Le lundi 17 juillet 2023, 22:49:16 CEST Slawomir Jaranowski a écrit :
> Hi
> 
> Please try a never version of Maven and m-resources-p
> Maven 3.3.9 is EOL - https://maven.apache.org/docs/history.html
> 
> m-resources-p has no parameter "resources"
m-resources-p has a resources parameter
https://github.com/apache/maven-resources-plugin/blob/master/src/main/java/org/apache/maven/plugins/resources/ResourcesMojo.java#L77

but as it is marked read-only, you're right that it's not documented, as it's 
not expected to be configured in a pom.xml
https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html

And if configured, as the user expects, it should fail instead of trying to 
configure.

@Nikos on your strange behaviour change detected in Maven 3.3.9, perhaps it's a 
consequence of https://issues.apache.org/jira/browse/MNG-5440
But again, given you're not supposed to configure this read-only parameter, 
this is an invalid usage

With Maven 3.9, you should get a warning when trying to configure:
https://issues.apache.org/jira/browse/MNG-7464

And in the future, I suppose we should switch from warning to fail.
But given it was not enforced since early 3.0, we need to move step by step to 
let users detect when they use a read-only parameter (sometimes, it has been 
useful...)

Regards,

Hervé

> 
> You should use resource configuration on project level not plugin
> configuration, like in example:
> https://maven.apache.org/plugins/maven-resources-plugin/examples/include-exc
> lude.html
> niedz., 16 lip 2023 o 17:19 Nikos Dragazis  napisał(a):
> > Hi everyone,
> > 
> > I'd like to expose a deviation in maven's behavior regarding readonly
> > parameters in plugins. It seems that, starting from version 3.3.9, maven
> > no longer ignores configuration parameters for readonly arguments.
> > 
> > In more detail:
> > 
> > I have a project that follows the `war` packaging lifecycle and I'd like
> > to parameterize some resource files. Therefore, I tried to use the
> > maven-resources-plugin with a configuration that looks like this:
> > ```
> > 
> > 
> >org.apache.maven.plugins
> >maven-resources-plugin
> >2.6
> >
> >
> >  
> >  
> >
> > 
> > src/main/resources/META-INF
> > 
> >  META-INF
> >  true
> >  
> >  
> >persistence.xml
> >  
> >  
> >
> >
> >
> > 
> > src/main/resources/META-INF
> > 
> >  META-INF
> >  false
> >  
> >  
> >persistence.xml
> >  
> >  
> >
> >
> >  
> >  
> >
> >
> > 
> > 
> > ```
> > When running the `resources` goal with maven 3.3.3, I noticed that maven
> > ignores the inclusion/exclusion lists from the plugin's configuration,
> > i.e., the plugin copies `persistence.xml` unfiltered. However, this is
> > not the case with maven 3.3.9, where it actually filters the file.
> > 
> > Later on, I figured that the `resources` parameter is readonly for the
> > `resources` goal, and it gets its default value from the build/resources
> > element. So, I would expect maven to either ignore the `resources`
> > parameter from the configuration of the `resources` goal (like what
> > happens in maven 3.3.3), or throw an error. That said, I find the
> > behavior of maven 3.3.9 unexpected.
> > 
> > I'd love any feedback on this.
> > 
> > Thanks,
> > Nikos
> > 
> > -
> > 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: Maven 3.3.9 allows overriding readonly parameters for plugins

[Hervé Boutemy]

Maven 3 not blocking setting read-only parameters is a known limitation
https://issues.apache.org/jira/browse/MNG-5001

in your case where you find a different behaviour between different Maven 3 
releases, I imagine it's an additional side effect of this parameter not really 
being expected to be configured like this

Perhaps recent "plugin verification" checks do check this: did you try with 
Maven 3.9.3?

Regards,

Hervé

Le dimanche 16 juillet 2023, 17:19:02 CEST Nikos Dragazis a écrit :
> Hi everyone,
> 
> I'd like to expose a deviation in maven's behavior regarding readonly
> parameters in plugins. It seems that, starting from version 3.3.9, maven
> no longer ignores configuration parameters for readonly arguments.
> 
> In more detail:
> 
> I have a project that follows the `war` packaging lifecycle and I'd like
> to parameterize some resource files. Therefore, I tried to use the
> maven-resources-plugin with a configuration that looks like this:
> ```
> 
>org.apache.maven.plugins
>maven-resources-plugin
>2.6
>
>  
>
> src/main/resources/META-INF
>  META-INF
>  true
>  
>persistence.xml
>  
>
>
> src/main/resources/META-INF
>  META-INF
>  false
>  
>persistence.xml
>  
>
>  
>
> 
> ```
> When running the `resources` goal with maven 3.3.3, I noticed that maven
> ignores the inclusion/exclusion lists from the plugin's configuration,
> i.e., the plugin copies `persistence.xml` unfiltered. However, this is
> not the case with maven 3.3.9, where it actually filters the file.
> 
> Later on, I figured that the `resources` parameter is readonly for the
> `resources` goal, and it gets its default value from the build/resources
> element. So, I would expect maven to either ignore the `resources`
> parameter from the configuration of the `resources` goal (like what
> happens in maven 3.3.3), or throw an error. That said, I find the
> behavior of maven 3.3.9 unexpected.
> 
> I'd love any feedback on this.
> 
> Thanks,
> Nikos
> 
> -
> 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: BOM files referencing optional dependencies

[Hervé Boutemy]

Yes
remember, BOM POM is "only" dependencyManagement, then it just locks version 
if the user importing the BOM POM adds the actual dependency: importing BOM 
POM makes the user just ready to eventually use anything easily

Regards,

Hervé

Le samedi 17 juin 2023, 21:32:24 CEST Ceki Gülcü a écrit :
> Hello,
> 
> Is it considered good practice to reference optional dependencies in BOM
> files?





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Hervé Boutemy]

> Guava has -jre
> and -android flavors on their artifact ID instead of using classifiers.
not exactly, they have the flavor as part of version string

https://central.sonatype.com/artifact/com.google.guava/guava/32.0.1-jre/
versions

which in fact looks like what François describes in another answer to the 
thread

Regards,

Hervé


Le lundi 12 juin 2023, 19:30:12 CEST Greg Chabala a écrit :
> Sure, individual projects have done things as they saw fit. Guava has -jre
> and -android flavors on their artifact ID instead of using classifiers.
> Bouncycastle is using ant for their build process. I wouldn't want to
> emulate either as best practice.
> 
> Scala, as an ecosystem, has decided on "_binaryVersion" appended to
> artifact ID, which feels gross.
> 
> The Maven POM reference ( https://maven.apache.org/pom.html ) is pretty
> clear: "The classifier distinguishes artifacts that were built from the
> same POM but differ in content. It is some optional and arbitrary string
> that - if present - is appended to the artifact name just after the version
> number. As a motivation for this element, consider for example a project
> that offers an artifact targeting Java 11 but at the same time also an
> artifact that still supports Java 1.8."
> 
> Binary compatibility versions are noise that should be in the classifier,
> if you're building from the same source tree, it only needs one artifact ID.





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Questions about the build cache plugin

[Hervé Boutemy]

reading the discussion about maintenance branch and "who updates the cache", I 
think that:

1. maintenance branch is like main branch: with Olivier's nice strategy, you 
should build fully. In fact, the few long-lived branches should be built 
fully, only the many PR short-lived branches should be built quickly with 
cache

2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT, 
ie the last publication wins over previous ones. With cache, any publication 
is just an addition of new content, indexed by input checksums. Then we don't 
really care about who is the first discovering a new input checksum, then 
filling the output cache for that new input checksum.

Really nice feedback on build cache extension in real life!

Thanks a lot to the contributor to this great feature

Regards,

Hervé

Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit :
> On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell  wrote:
> > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy 
:
> > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell  
wrote:
> > > > Hello everyone!
> > > > 
> > > > First of all thank you everyone working on the build cache plugin! It
> > > > is amazing!
> > > > 
> > > > At least some of  the following questions seem to be of interest to
> > > > most users and might end up on the documentation, So here's a few
> > > > things which came to my mind.
> > > > 
> > > > 1.) Considering I always require PRs in my projects, would setting
> > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > > > for the main branch?
> > > 
> > > Personally, I would have the main branch always have a full build
> > > without caching to be sure everything works fine but use cache only
> > > for branches/PR :)
> > > That's what we will do at Jetty project.
> > > The build for 12 branch is around 50 minutes with the cache it goes
> > > down to 8/9 minutes (only because something is always rebuilt and
> > > retrigger a few small modules)
> > > The idea is to reduce development/check of PR and use some incremental
> > > build while the main is always fully build especially when the build
> > > has few jdks as target.
> > > But here it's up to you :)
> > 
> > I can see your point, but who is updating the remote cache then?
> 
> every PR potentially updates the cache. depending on changes per PR
> some module cache will be shared or not with other PRs.
> We (Jetty project) have decided to not have any publicity open remote
> cache setup per default as we do not have the infra for this (but CI
> use a private one)
> but in a company context or if you have the infra for this it might be
> a better option.
> 
> > > > 2.) Can I maybe have  the branch name included in a path to a remote?
> > > > This way I could have a different cache for maintenance branches. Just
> > > > include the branch name into -Dmaven.build.cache.remote.url?
> > > 
> > > why would need that?
> > > if your branch has different sources (java, pom, etc..) the calculated
> > > hash will be different so the hash key will be simply different no
> > > need to configure a cache URL differently (well except if you want to
> > > clean up caches per branch)
> > 
> > It depends on what you might be trying to do. For projects with new
> > major versions and some
> > big refactoring done in the past, this did sound sensible to me.
> > What is the cache worth if there's 0% hit on the maintenance branch?
> 
> hit ratio will depend on the changes you do.
> parent pom change -> everything will be rebuilt
> single java source in a module: only this module and dependant will be
> rebuilt. Finally, there is no single rule on how to use/configure the
> cache, the usage depends on how a team is working, what sort of change they
> often have, etc...
> first, have your build working (if it's complicated one you may have
> some extra configuration to add)
> 
> > > > 3.) Can I somehow use option 1 & 2 to make caches available for
> > > > colleagues without making them manually configure the remote URL for
> > > > each branch they are working on?
> > > 
> > > cache will be used by colleagues' build as long as a module have the
> > > same calculated hash any local differences will have a different
> > > calculated hash
> > 
> > Same as above:
> > What about devs working on a maintenance branch when main has seen big
> > refactoring?
> > 
> > > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > > > say WHEN to use them (only that they may leverage performance). Are
> > > > there some example cases or does someone already have some experience
> > > > we could benefit from?
> > > 
> > > I have yet to see huge differences.
> > > currently with a build already down from 50 minutes to 8/9 minutes not
> > > sure this was my primary goal
> > > So I can't really tell :)
> > 
> > Well, it is listed under "performance tuning", so I concluded it might
> > make a difference.
> > Will probably go for XX (because it is mentioned as 

[ANN] Apache Maven GPG Plugin 3.1.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
3.1.0 Plugin, version 3.1.0

This plugin signs all of the project's attached artifacts with GnuPG.

https://maven.apache.org/plugins/maven-gpg-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-gpg-plugin
  3.1.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-gpg-plugin/download.cgi

Release Notes - Maven GPG Plugin - Version 3.1.0

** Bug
* [MGPG-44] - gpg:sign does not handle non-Default outputDirectory correctly
* [MGPG-86] - NullPointerException when gpg executable cannot be found
* [MGPG-87] - NullPointerException when gpg not installed

** Improvement
* [MGPG-95] - don't GPG-sign .sigstore signatures
* [MGPG-96] - add INFO message when signing
* [MGPG-97] - add pgpverify check to the build

** Task
* [MGPG-88] - Require Java 8

** Dependency upgrade
* [MGPG-89] - Upgrade parent POM to version 36
* [MGPG-94] - Update parent pom to 39

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Assembly Plugin 3.5.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Assembly Plugin, version 3.5.0

This plugin builds an assembly (distribution) of sources and/or binaries.

https://maven.apache.org/plugins/maven-assembly-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-assembly-plugin
  3.5.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-assembly-plugin/download.cgi

Release Notes - Maven Assembly Plugin - Version 3.5.0

** Bug
* [MASSEMBLY-941] - file permissions removed during assembly:single since 
3.2.0


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: Side effects of import scope?

[Hervé BOUTEMY]

Le lundi 22 août 2022, 14:41:56 CEST Delany a écrit :
> Hi Herve,
Hi Delany,
Sorry for the late answer, I was away...

> 
> The bom flattenMode in
> https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html
> is "Like ossrh but additionally keeps dependencyManagement and properties"
> 
> If the properties are not going to be available to the importing project,
> why not resolve them in dependencyManagement and leave them out of the bom?
I don't know why this choice was done: perhaps because keeping them in BOM is 
easier, then why doing more work in the flatten-maven-plugin?

> Alternatively, if dependencyManagement should remain unresolved, why not
> import the properties, allowing them to be overwritten by the importing
> project?
who said dependencyManagement should remain unresolved?
(notice that I suppose by "unresolved" you mean with properties not 
interpolated: "resolving" has a different meaning in dependency resolution 
context, then sorry, but I need to be picky on terms)


in fact, dependencyManagement import is currently coded as I explained and 
showed in code, which is not well known by many nor have a definitive 
documentation of intent AFAIK.
Its purpose is "basic dependencyManagement import", where "basic" is about 
importing effective values.
If properties could be injected from importing project to the BOM, this would 
mean "parametrized import": this is a different use case.
If properties from bom leaked to importing project, it would not only be 
"dependencyManagement import", but "dependencyManagement and properties 
import": and precedence rules could be tricky

having properties out of import features was IMHO a great design decision for 
the intent = importing something clearly defined.

Regards,

Hervé

> 
> Regards,
> Delany
> 
> On Mon, 22 Aug 2022 at 14:28,  wrote:
> > saying "publish these properties in a bom?" is confusing: properties from
> > the BOM are not published
> > 
> > the BOM is written using a property, for simplicity for example of
> > defining a version that is used by many dependencies
> > 
> > but that's to ease BOM writer maintenance: it does not publish anything to
> > BOM consumer
> > 
> > Regards,
> > 
> > Hervé
> > 
> > - Mail original -
> > De: "Delany" 
> > À: "Maven Users List" 
> > Envoyé: Vendredi 19 Août 2022 12:43:55
> > Objet: Re: Side effects of import scope?
> > 
> > >> I don't see how any property from the imported model could affect the
> > >> importing model
> > > 
> > > OK, good to know.
> > 
> > It also can't be overwritten from the importing model, so what purpose
> > does
> > it serve to publish these properties in a bom?
> > 
> > Regards,
> > Delany
> > 
> > On Thu, 18 Aug 2022 at 20:56, Laird Nelson  wrote:
> > > On Wed, Aug 17, 2022 at 11:33 PM Herve Boutemy 
> > > 
> > > wrote:
> > > > I see one clarification to add to your "by value" explanation: what is
> > > > imported is the dependencyManagement content from the *effective*
> > > 
> > > imported
> > > 
> > > > model, ie with its interpolation  (properties substitution) already
> > 
> > done
> > 
> > > That's helpful; thanks.
> > > 
> > > > I don't see how any property from the imported model could affect the
> > > > importing model
> > > 
> > > OK, good to know.
> > > 
> > > > A few reference to source code:
> > 
> > > > - the importer:
> > https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/mav
> > en/model/composition/DefaultDependencyManagementImporter.html> 
> > > > - and the effective model resolution that happens before:
> > https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/mav
> > en/model/building/DefaultModelBuilder.html#L1236> 
> > > > Hope this helps
> > > 
> > > Very much, thanks.
> > > 
> > > L
> > 
> > -
> > 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: How to tell maven to use https instead of http...

[Hervé BOUTEMY]

what version of Maven Archetype Plugin do you get?
And what is the output before the exception?

Regards,

Hervé

Le dimanche 19 juin 2022, 19:11:27 CEST Stefano Fornari a écrit :
> I am trying to create a project from an archetype:
> 
> mvn archetype:generate \
> -DarchetypeGroupId=org.openjfx \
> -DarchetypeArtifactId=javafx-archetype-simple \
> -DarchetypeVersion=0.0.3 \
> -DgroupId=org.openjfx \
> -DartifactId=sample \
> -Dversion=1.0.0 \
> -Djavafx-version=17.0.1
> 
> 
> But I am getting the following error:
> 
> rg.apache.maven.wagon.TransferFailedException: Failed to transfer file:
> http://repo1.maven.org/maven2. Return code is: 501 , ReasonPhrase:HTTPS
> Required.
> 
> Shouldn't maven central be hardcoded in the apache-maven package? How can I
> fix it?
> 
> Many thanks in advance.
> 
> Ste





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Any plans to release maven-checkstyle-plugin?

[Hervé BOUTEMY]

description from the CVE:
An attacker that is able to modify Velocity templates may execute arbitrary 
Java code or run arbitrary system commands with the same privileges as the 
account running the Servlet container. This applies to applications that allow 
untrusted users to upload/modify velocity templates running Apache Velocity 
Engine versions up to 2.2. 


In the context of a Maven build, executing arbitrary code does not even 
require Velocity...

of course, while doing a release, upgrading Velocity is something to do


Le mercredi 18 mai 2022, 05:37:44 CEST Maxim Solodovnik a écrit :
> BTW org.apache.velocity:velocity used in 3.1.2 is reported as
> vulnerable here:
> https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-checkstyle
> -plugin/3.1.2
> On Fri, 22 Apr 2022 at 10:42, Maxim Solodovnik  wrote:
> > 3.2.0-SNAPSHOT works as expected
> > at least "Instanceof pattern matching" seems to pass checkstyle :)
> > 
> > On Thu, 21 Apr 2022 at 19:21, Falko Modler  wrote:
> > > Hi Maxim,
> > > 
> > > it works for me when adding checkstyle 9.3 (or other recent versions) as
> > > a plugin dependency, overriding the one that is shipped by the plugin.
> > 
> > This might be the option, but this way I should do manual updates all
> > the time :(
> > maven-checkstyle-plugin was released 2021-01-23 (more than a year ago)
> > IMO it's time to release :)
> > 
> > > I never wait for plugin updates to update checkstyle, because checkstlye
> > > is updated way more often than the plugin.
> > > 
> > > Cheers,
> > > 
> > > Falko
> > > 
> > > Am 21.04.2022 um 11:51 schrieb Maxim Solodovnik:
> > > > Hello All,
> > > > 
> > > > I would like to switch to the latest Java17 LTS
> > > > But it seems latest maven-checkstyle-plugin doesn't work with new
> > > > java17 features :(
> > > > 
> > > > Maybe it would be possible to release new version?
> > > > 
> > > > Thanks in advance :)
> > > 
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > --
> > Best regards,
> > Maxim





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Wrapper 3.1.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Wrapper, version 3.1.1.

The Maven Wrapper is an easy way to ensure a user of your Maven build has 
everything necessary to run your Maven build.

This is the first release of this project in its Apache Maven new home: it was 
previously maintained by community at https://github.com/takari/maven-wrapper 
and was kindly donated to the Maven team. Thank you to all people who 
permitted this.

See https://maven.apache.org/wrapper/ for instructions on how to use this 
updated Maven Wrapper.

You can download the appropriate sources etc. from the download page:

https://maven.apache.org/wrapper/download.cgi


Release Notes - Maven Wrapper - Version 3.1.1

** Bug
* [MWRAPPER-21] - Arbitrary file write during archive extraction ("Zip 
Slip") in wrapper
* [MWRAPPER-38] - build from source-release has different result from Git
* [MWRAPPER-40] - Wrapper Properties File License system dependant line 
separator
* [MWRAPPER-41] - Goals documentation missing from site
* [MWRAPPER-42] - maven-wrapper fails to self-update maven-wrapper.jar
* [MWRAPPER-44] - maven-wrapper may use outdated 
MavenWrapperDownloader.class
* [MWRAPPER-58] - curl cannot follow 302 code when downloading wrapper jar

** Improvement
* [MWRAPPER-39] - release as maven-wrapper instead of maven-wrapper-parent
* [MWRAPPER-43] - Download of jar must be quiet by default
* [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/
scripts
* [MWRAPPER-49] - add Wrapper version in mvnw/mvnw.cmd scripts
* [MWRAPPER-51] - Refactor using Java Path API (NIO.2)
* [MWRAPPER-53] - cygwin path tidy for java and class

** Task
* [MWRAPPER-56] - Remove M2_HOME from mvnw script

** Dependency upgrade
* [MWRAPPER-62] - Upgrade Parent to 35
* [MWRAPPER-63] - Upgrade Parent to 36


Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Artifact Plugin 3.3.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Artifact Plugin, version 3.3.0

This plugins provides tools to manage artifacts tasks.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.3.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-artifact-plugin/download.cgi

Release Notes - Maven Artifact Plugin - Version 3.3.0

** Bug
* [MARTIFACT-31] - wrong comparison results when buildinfo has been 
published to Central

** New Feature
* [MARTIFACT-24] - add artifact:check-buildplan goal to check that plugins 
versions do not have known reproducibility issues


see also updated guide to Reproducible Builds 
https://maven.apache.org/guides/mini/guide-reproducible-builds.html

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Parent POMs 35 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Maven Parent 
POMs Version 35.
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
   35


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-35

** Bug
* [MPOM-242] - fix mono-module site easy-deployment
* [MPOM-243] - WARNING: release:perform issues [WARNING] The requested 
profile "pom.xml" could not be activated because it does not exist.
* [MPOM-253] - issue management URL incorrect

** New Feature
* [MPOM-274] - use Shared GitHub Actions

** Improvement
* [MPOM-268] - Removed unused property
* [MPOM-276] - streamLogsOnFailures for maven-invoker-plugin as default
* [MPOM-278] - add "Extensions" entry to "Maven Projects" menu
* [MPOM-279] - Get rid of findbugs-maven-plugin
* [MPOM-280] - Remove detectLinks from maven-javadoc-plugin
* [MPOM-298] - Cleanup dependencyLocationsEnabled from MPIR configuration 

** Task
* [MPOM-270] - Fix enforcer use
* [MPOM-271] - Create helper profile to "ban legacy"
* [MPOM-272] - Remove legacy from doxia parent depMgmg
* [MPOM-273] - Update maven-plugin-plugin to 3.6.2
* [MPOM-281] - Update maven-plugin-plugin to 3.6.4

** Dependency upgrade
* [MPOM-239] - upgrade plexus-component-metadata to 2.1.0 for better 
Reproducible Build
* [MPOM-250] - remove the JavaDoc taglets from maven-parent (both to 
extract Mojo javadoc annotations and link in javadoc)
* [MPOM-292] - upgrade parent to ASF 25

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: martifact won't inherit project.build.outputTimestamp

[Hervé BOUTEMY]

Le jeudi 10 février 2022, 14:35:58 CET Delany a écrit :
> Thanks I'll send PR.
thank you for helping

> Since you ask, I think Maven should allow silencing any warning for any
> plugin, but that's for another day.
sure :)

> 
> I'm not able to compare builds. I run `mvn clean install`, and `mvn clean
> package artifact:compare` and I get an error "could not find repository
> with id = central"
ok, you're not in the easy setup: I suppose that you have a setting.xml that 
defines a mirror for central

you'll need to "mvn clean package artifact:compare -Dreference.repo=xxx"
with a value of repository that works for you

I suppose the goal can be improved to support installed artifacts even if no 
remote repository is available: this is an edge case that I personally never 
needed, and of course, I'm coding the features I need first...

...

> Is there really an "apache-maven-3.8.4-SNAPSHOT.buildinfo" available at
> Central?
no need for buildinfo to be stored anywhere: it's an internal temporary detail 
during the comparison process

then no need to add artifact plugin to your pom.xml: you just need to call 
artifact:compare on CLI when checking current build against a previous 
reference build
(focus on buildinfo in early days of my work on Reproducible Builds has been 
found as finally a wrong idea: artifact:compare is the important goal, that 
does its job without needing anything to be published to repositories)

> 
> Regards,
good feedback, thank you

Regards,

Hervé

> Delany
> 
> On Thu, 10 Feb 2022 at 04:46, Hervé BOUTEMY  wrote:
> > Le mercredi 9 février 2022, 09:31:00 CET Delany a écrit :
> > > Hi Herve,
> > > 
> > > I see you already check that the project.parent was part of the reactor
> > 
> > and
> > 
> > > you don't issue the warning if it is.
> > > An edge case is the -rf switch. Even though you have the opportunity to
> > > change files, the sense is that it is the same build being resumed, so I
> > > would also not warn in this case.
> > 
> > PRs welcome
> > and eventually an evaluation of "is this purely theory or really a use
> > case
> > I'll face?" aspect: I honestly don't see why I would do a reproducibility
> > check with "-pr", or if it while making precisely one module reproducible,
> > the
> > message is not ideal but not really harmful
> > 
> > > The word parent can have two meanings here so rather avoid it in the
> > > message. If the project.parent is not part of the build, then can you
> > 
> > warn
> > 
> > > 'outputTimestamp is inherited from groupId:artifactId but it is not
> > > included in the build'.
> > 
> > message is coded here
> > https://github.com/apache/maven-artifact-plugin/blob/
> > master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/
> > AbstractBuildinfoMojo.java#L158
> > <https://github.com/apache/maven-artifact-plugin/blob/master/src/main/java
> > /org/apache/maven/plugins/artifact/buildinfo/AbstractBuildinfoMojo.java#L1
> > 58>
> > 
> > gives at runtime:
> > 
> > [WARNING] project.build.outputTimestamp property should not be inherited
> > but
> > defined in parent POM from reactor /home/me/project/pom.xml
> > 
> > please propose rephrasing
> > 
> > > If you make this warning configurable then a more in-depth explanation
> > > could be included in that documentation.
> > 
> > what do you think should be configurable?
> > 
> > > BTW the build commands you gave suggest that artifact:compare will use
> > 
> > the
> > 
> > > local Maven repository as its reference repo. Isn't this a more sensible
> > > default?
> > 
> > I gave commands to locally test during SNAPSHOT development, to detect and
> > fix
> > if there are issues: then yes, in that case, comparison is done between 2
> > local builds, that's why the first command need to be install
> > 
> > If it's about a release that has been published (eventually by someone
> > else),
> > "of course" you should do the first "install" run but only the second
> > "package
> > artifact:compare", and you'll see that by default it compares against
> > central
> > Just try to rebuild an artifact that was published by someone else = the
> > ultimate goal, to check that you can rebuild what you are downloading
> > 
> > and FYI, the Reproducible Central project is about rebuilding and checking
> > such artifacts from central:
> > https://github.com/jvm-repo-rebuild/reproducible-central
> > 
> >

Re: martifact won't inherit project.build.outputTimestamp

[Hervé BOUTEMY]

Le mercredi 9 février 2022, 09:31:00 CET Delany a écrit :
> Hi Herve,
> 
> I see you already check that the project.parent was part of the reactor and
> you don't issue the warning if it is.
> An edge case is the -rf switch. Even though you have the opportunity to
> change files, the sense is that it is the same build being resumed, so I
> would also not warn in this case.
PRs welcome
and eventually an evaluation of "is this purely theory or really a use case 
I'll face?" aspect: I honestly don't see why I would do a reproducibility 
check with "-pr", or if it while making precisely one module reproducible, the 
message is not ideal but not really harmful

> 
> The word parent can have two meanings here so rather avoid it in the
> message. If the project.parent is not part of the build, then can you warn
> 'outputTimestamp is inherited from groupId:artifactId but it is not
> included in the build'.
message is coded here https://github.com/apache/maven-artifact-plugin/blob/
master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/
AbstractBuildinfoMojo.java#L158

gives at runtime:

[WARNING] project.build.outputTimestamp property should not be inherited but 
defined in parent POM from reactor /home/me/project/pom.xml

please propose rephrasing

> If you make this warning configurable then a more in-depth explanation
> could be included in that documentation.
what do you think should be configurable?

> 
> BTW the build commands you gave suggest that artifact:compare will use the
> local Maven repository as its reference repo. Isn't this a more sensible
> default?
I gave commands to locally test during SNAPSHOT development, to detect and fix 
if there are issues: then yes, in that case, comparison is done between 2 
local builds, that's why the first command need to be install

If it's about a release that has been published (eventually by someone else), 
"of course" you should do the first "install" run but only the second "package 
artifact:compare", and you'll see that by default it compares against central
Just try to rebuild an artifact that was published by someone else = the 
ultimate goal, to check that you can rebuild what you are downloading

and FYI, the Reproducible Central project is about rebuilding and checking 
such artifacts from central:
https://github.com/jvm-repo-rebuild/reproducible-central

Regards,

Hervé

> 
> Thanks,
> Delany
> 
> On Wed, 9 Feb 2022 at 09:25, Hervé BOUTEMY  wrote:
> > Hi Delany,
> > 
> > Good question: let's see if we can improve the message that I added in
> > MARTIFACT-28 [1]
> > 
> > First, remember that it's all about Reproducible Builds [2].
> > As described in the MARTIFACT-28 issue, inheriting the parent pom release
> > timestamp technically works (it gives a reproducible value to your current
> > build), but does not match the current release/build timestamp: you
> > probably
> > prefer to have a timestamp defined in your reactor
> > = that is the message that we need to make as clear as possible
> > 
> > Don't hesitate to propose an updated message that fits inclusion in a
> > plugin
> > output...
> > 
> > 
> > Notice that I'm surprised of your choice to set the outputTimestamp to $
> > {maven.build.timestamp}, given this value is not reproducible (if you
> > build 2
> > time the same code, you'll get 2 different values), choosing this value
> > defeats
> > the whole purpose of the configuration.
> > Remember, it's all about Reproducible Builds, and your objective is to run
> > the
> > build 2 times and check you get the same binary output:
> > 
> > mvn clean install
> > mvn clean package artifact:compare
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://issues.apache.org/jira/browse/MARTIFACT-28
> > 
> > [2] https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > 
> > Le mardi 8 février 2022, 11:04:33 CET Delany a écrit :
> > > Hi. Why does maven-artifact-plugin complain
> > > 
> > >   [WARNING] project.build.outputTimestamp property should not be
> > 
> > inherited
> > 
> > > but defined in parent POM from reactor
> > > 
> > > I never had a plugin complain about utilizing inheritance. Why does it
> > 
> > care?
> > 
> > > When I add the line to the project the warning disappears
> > 
> > ${maven.build.timestamp} > pu> 
> > > tTimestamp>
> > > 
> > > Thanks,
> > > Delany
> > 
> > -
> > 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: martifact won't inherit project.build.outputTimestamp

[Hervé BOUTEMY]

Hi Delany,

Good question: let's see if we can improve the message that I added in 
MARTIFACT-28 [1]

First, remember that it's all about Reproducible Builds [2].
As described in the MARTIFACT-28 issue, inheriting the parent pom release 
timestamp technically works (it gives a reproducible value to your current 
build), but does not match the current release/build timestamp: you probably 
prefer to have a timestamp defined in your reactor
= that is the message that we need to make as clear as possible

Don't hesitate to propose an updated message that fits inclusion in a plugin 
output...


Notice that I'm surprised of your choice to set the outputTimestamp to $
{maven.build.timestamp}, given this value is not reproducible (if you build 2 
time the same code, you'll get 2 different values), choosing this value defeats 
the whole purpose of the configuration.
Remember, it's all about Reproducible Builds, and your objective is to run the 
build 2 times and check you get the same binary output:

mvn clean install
mvn clean package artifact:compare

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MARTIFACT-28

[2] https://maven.apache.org/guides/mini/guide-reproducible-builds.html

Le mardi 8 février 2022, 11:04:33 CET Delany a écrit :
> Hi. Why does maven-artifact-plugin complain
> 
>   [WARNING] project.build.outputTimestamp property should not be inherited
> but defined in parent POM from reactor
> 
> I never had a plugin complain about utilizing inheritance. Why does it care?
> When I add the line to the project the warning disappears
> 
> 
> ${maven.build.timestamp} tTimestamp>
> 
> Thanks,
> Delany





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Question for Maven Plugin developers/maintainers

[Hervé BOUTEMY]

= the maven-script part of https://maven.apache.org/plugin-tools/index.html

Le mardi 1 février 2022, 09:16:36 CET Tamás Cservenák a écrit :
> Howdy,
> 
> Yes, the reason for this question was to deprecate the "scripting" bit of
> maven-plugin-tools, as many of us did not see such a beast in a while
> 
> T
> 
> On Tue, Feb 1, 2022 at 2:10 AM Manfred Moser 
> 
> wrote:
> > Fair enough and good examples for using beanshell in the pom. My point was
> > mostly that there are alternatives.
> > 
> > Also from all I understand Tamás asked about implementing part of a plugin
> > in beanshell. That is what you are
> > avoiding by doing it in the POM. And if you were to implement a plugin I
> > would assume would also choose Java.
> > I know I would ;-)
> > 
> > 
> > Manfred
> > 
> > Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
> > > I am replying to Manfred rather than to Tamás, because I am only
> > > contributing to one plugin, and it is not using any Beanshell stuff. But
> > > I do use Beanshell scripting in a few projects where it is difficult too
> > > avoid, because I have not found any proper plugins to do what I need.
> > > 
> > > Examples include:
> > >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >   
> > >  bsh-property, in order to unpack certain classes from Java 9+ JREs,
> > >  using the jimage executable. I am doing this in order to instrument
> > >  same classes and then prepend them to the bootclasspath using
> > >  '--path-module' in some situations. If Maven JMOD Plugin was not
> > >  dead, maybe that would be an alternative. But today it is not. You
> > >  cannot do a lot with that plugin. Besides, for the Java 8 profile
> > >  in the same project, I use Antrun with a simple unzip task in order
> > >  to extract the same classes from tools.jar. That is easier, no
> > >  extra BeanShell scripting needed.
> > >   
> > >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >   
> > >  bsh-property, in order to create a marker file after some expensive
> > >  steps (downloading and unpacking certain dependencies in order to
> > >  create a specific directory structure), so that in later builds a
> > >  file-based property does not activate the same profile again,
> > >  avoiding the downloading and unpacking in later builds. Why I am
> > >  doing that is complicated. Basically, it is because not all the
> > >  files I am downloading are available on Maven Central, so I cannot
> > >  simply use the Dependency plugin.
> > > 
> > > An alternative to Beanshell would be Groovy scripting in the above
> > > cases, but pulling in heavy Groovy stuff for a little script in projects
> > > which otherwise do not use Groovy seems to be a bit costly.
> > > 
> > > So Beanshell as such might be dead to some people, but even I who
> > > otherwise claims to hate scripted builds cannot avoid it sometimes,
> > > basically because I am too lazy to write my own Maven plugins, because I
> > > do not wish to learn how to do so. Sometimes I just want to get
> > > something done and usually have tried 5 other ways to solve the same
> > > problem before yielding and resorting to Beanshell inside a POM.
> > > 
> > > --
> > > Alexander Kriegisch
> > > https://scrum-master.de
> > > 
> > > Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> > >> I think beanshell is long dead. Any plugin that uses it would be for a
> > >> very old Maven version and would need a lot of work when upgrading. So
> > >> we should be okay to deprecate
> > >> 
> > >> And in terms of ANT .. if there are any out there.. similar things
> > >> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> > >> is available as escape hatch as well.
> > >> 
> > >> And there is also
> > >> https://maven.apache.org/plugins/maven-scripting-plugin/
> > >> 
> > >> So overall.. I would say we are ok to deprecate that support.
> > >> 
> > >> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> > >>> We'd like to get some feedback from anyone who implemented,
> > >>> maintained or plans to implement a Maven Plugin (Mojo):
> > >>> 
> > >>> Did any of you see a Maven Plugin that is NOT implemented in Java
> > >>> (but uses Ant or Beanshell scripting)?
> > >>> 
> > >>> Currently implementing Maven Plugins with these scripting solutions
> > >>> is possible, we are not aware of any uses of it. Hence, we would like
> > >>> to deprecate support for these (naturally, based on user responses).
> > > 
> > > -
> > > 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: [maven-scm-publish-plugin] Could not copy content to SCM checkout... source... and destination... are the same

[Hervé BOUTEMY]

I opened a Jira issue, because in such misconfiguration, we can have a better 
message:
https://issues.apache.org/jira/browse/MSCMPUB-48

please help me refining the improved message

Thanks

Hervé

Le samedi 8 janvier 2022, 23:48:08 CET Lewis John McGibbney a écrit :
> Thank you VERY much Hervé.
> I looked at this code when I was tired and didn't see it.
> Have a great weekend.
> lewismc
> 
> On 2022/01/08 19:10:10 Hervé BOUTEMY wrote:
> > Hi,
> > 
> > I was able to reproduce your issue.
> > 
> > If you read the log, there is no issue with svn command.
> > The issue is when doing:
> > [INFO] Updating checkout directory with actual content in /Users/lmcgibbn/
> > Downloads/any23/any23-site
> > 
> > and the error message is:
> > Could not copy content to SCM checkout: Source 'xxx' and destination 'xxx'
> > are the same -> [Help 1]
> > 
> > and it's true:
> > https://github.com/apache/any23/blob/master/pom.xml#L1244
> > 
> > content value = ${site.filePath}
> > checkoutDirectory = ${site.scmPubCheckoutDirectory} = ${site.filePath} (as
> > defined in properties)
> > 
> > that's not normal: content value should be something like target/site or
> > target/staging
> > 
> > 
> > see plugin documentation
> > https://maven.apache.org/plugins/maven-scm-publish-plugin/
> > 
> > (eventually contact me on ASF Slack...)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 8 janvier 2022, 08:48:12 CET lewis john mcgibbney a écrit :
> > > Hi scm-users@,
> > > Plugin configuration is as follows
> > > 
> > >   
> > >   
> > > org.apache.maven.plugins
> > > maven-scm-publish-plugin
> > > 3.1.0
> > > 
> > > 
> > >   true
> > >   Apache Any23 ${project.version} site
> > > 
> > > deployment
> > > 
> > > ${site.scmPubCheckoutDirectory}
> > > 
> > >   ${site.deploymentBaseUrl}
> > >   ${site.filePath}
> > > 
> > > 
> > >   
> > >   
> > > 
> > > When I execute it as part of the Apache Any23 website release (
> > > https://github.com/apache/any23/blob/master/deploy-site.sh#L20) it fails
> > > with the following
> > > 
> > > [INFO] --- maven-scm-publish-plugin:3.1.0:publish-scm (default-cli) @
> > > apache-any23 ---
> > > [INFO] Updating the pub tree from scm:svn:
> > > https://svn.apache.org/repos/asf/any23/site into
> > > /Users/lmcgibbn/Downloads/any23/any23-site
> > > [INFO] Executing: /bin/sh -c cd
> > > /Users/lmcgibbn/Downloads/any23/any23-site
> > > && svn --username lewismc --password '*' --no-auth-cache
> > > --non-interactive update /Users/lmcgibbn/Downloads/any23/any23-site@
> > > [INFO] Updating checkout directory with actual content in
> > > /Users/lmcgibbn/Downloads/any23/any23-site
> > > [INFO]
> > > 
> > > [INFO] Reactor Summary for Apache Any23 2.7-SNAPSHOT:
> > > [INFO]
> > > [INFO] Apache Any23 ... FAILURE [
> > > 
> > >  2.957 s]
> > > 
> > > [INFO] Apache Any23 :: Base API ... SUCCESS [
> > > 23.288 s]
> > > [INFO] Apache Any23 :: Test Resources . SUCCESS [
> > > 
> > >  9.331 s]
> > > 
> > > [INFO] Apache Any23 :: CSV Utilities .. SUCCESS [
> > > 14.311 s]
> > > [INFO] Apache Any23 :: Mime Type Detection  SUCCESS [
> > > 20.215 s]
> > > [INFO] Apache Any23 :: Encoding Detection . SUCCESS [
> > > 18.632 s]
> > > [INFO] Apache Any23 :: Core ... SUCCESS [
> > > 32.095 s]
> > > [INFO] Apache Any23 :: CLI  SUCCESS [
> > > 21.820 s]
> > > [INFO]
> > > 
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > > 
> > > [INFO] Total time:  02:55 min
> > > [INFO] Finished at: 2022-01-07T23:20:55-08:00
> > > [INFO]
> > > 
>

Re: [maven-scm-publish-plugin] Could not copy content to SCM checkout... source... and destination... are the same

[Hervé BOUTEMY]

Hi,

I was able to reproduce your issue.

If you read the log, there is no issue with svn command.
The issue is when doing:
[INFO] Updating checkout directory with actual content in /Users/lmcgibbn/
Downloads/any23/any23-site

and the error message is:
Could not copy content to SCM checkout: Source 'xxx' and destination 'xxx' are 
the same -> [Help 1]

and it's true:
https://github.com/apache/any23/blob/master/pom.xml#L1244

content value = ${site.filePath}
checkoutDirectory = ${site.scmPubCheckoutDirectory} = ${site.filePath} (as 
defined in properties)

that's not normal: content value should be something like target/site or 
target/staging


see plugin documentation
https://maven.apache.org/plugins/maven-scm-publish-plugin/

(eventually contact me on ASF Slack...)

Regards,

Hervé


Le samedi 8 janvier 2022, 08:48:12 CET lewis john mcgibbney a écrit :
> Hi scm-users@,
> Plugin configuration is as follows
> 
>   
> org.apache.maven.plugins
> maven-scm-publish-plugin
> 3.1.0
> 
>   true
>   Apache Any23 ${project.version} site
> deployment
> 
> ${site.scmPubCheckoutDirectory}
>   ${site.deploymentBaseUrl}
>   ${site.filePath}
> 
>   
> 
> When I execute it as part of the Apache Any23 website release (
> https://github.com/apache/any23/blob/master/deploy-site.sh#L20) it fails
> with the following
> 
> [INFO] --- maven-scm-publish-plugin:3.1.0:publish-scm (default-cli) @
> apache-any23 ---
> [INFO] Updating the pub tree from scm:svn:
> https://svn.apache.org/repos/asf/any23/site into
> /Users/lmcgibbn/Downloads/any23/any23-site
> [INFO] Executing: /bin/sh -c cd /Users/lmcgibbn/Downloads/any23/any23-site
> && svn --username lewismc --password '*' --no-auth-cache
> --non-interactive update /Users/lmcgibbn/Downloads/any23/any23-site@
> [INFO] Updating checkout directory with actual content in
> /Users/lmcgibbn/Downloads/any23/any23-site
> [INFO]
> 
> [INFO] Reactor Summary for Apache Any23 2.7-SNAPSHOT:
> [INFO]
> [INFO] Apache Any23 ... FAILURE [
>  2.957 s]
> [INFO] Apache Any23 :: Base API ... SUCCESS [
> 23.288 s]
> [INFO] Apache Any23 :: Test Resources . SUCCESS [
>  9.331 s]
> [INFO] Apache Any23 :: CSV Utilities .. SUCCESS [
> 14.311 s]
> [INFO] Apache Any23 :: Mime Type Detection  SUCCESS [
> 20.215 s]
> [INFO] Apache Any23 :: Encoding Detection . SUCCESS [
> 18.632 s]
> [INFO] Apache Any23 :: Core ... SUCCESS [
> 32.095 s]
> [INFO] Apache Any23 :: CLI  SUCCESS [
> 21.820 s]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  02:55 min
> [INFO] Finished at: 2022-01-07T23:20:55-08:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:3.1.0:publish-scm
> (default-cli) on project apache-any23: Could not copy content to SCM
> checkout: Source
> '/Users/lmcgibbn/Downloads/any23/any23-site/.svn/pristine/61/617e72262042de8
> cf1f11bc8e3aaa231669f181a.svn-base' and destination
> '/Users/lmcgibbn/Downloads/any23/any23-site/.svn/pristine/61/617e72262042de8
> cf1f11bc8e3aaa231669f181a.svn-base' are the same -> [Help 1]
> 
> As you can see the svn update configuration seems to add an at character in
> the website checkout directory /Users/lmcgibbn/Downloads/any23/any23-site@
> 
> Can someone explain why this is happening and does anyone have a suggestion
> for how I fix it?
> 
> I also saw https://issues.apache.org/jira/browse/SCM-859 and I looked at
> the corresponding pull request but there is not too much context.
> 
> Thanks for any assistance.
> 
> lewismc





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Archetype Plugin 3.2.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Archetype Plugin, version 3.2.1

The Archetype Plugin allows the user to create a Maven project from an existing 
template called an archetype.
It also allows the user to create an archetype from an existing project.

https://maven.apache.org/archetype/maven-archetype-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-archetype-plugin
  3.2.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/archetype/download.cgi

Release Notes - Maven Archetype - Version 3.2.1

** Bug
* [ARCHETYPE-308] - Should ask input for requiredProperty with defaultValue
* [ARCHETYPE-406] - Support of velocity expressions for user-defined 
properties
* [ARCHETYPE-531] - NullPointerException when module not specified or 
config empty in EAR plugin
* [ARCHETYPE-565] - Unable to resolve groovy.json classes when planting
* [ARCHETYPE-605] - Allow .gitignore file in archetype resources
* [ARCHETYPE-606] - There is no way to include .gitignore files for the jar 
goal
* [ARCHETYPE-618] - Some complex default value expressions trigger 
NullPointerException
* [ARCHETYPE-620] - plexus-interactivity-1.0 bug is triggered since maven 
3.8.2
* [ARCHETYPE-622] - maven-archetype-plugin integration-test doesn't use 
Maven settings from the main build

** New Feature
* [ARCHETYPE-558] - Allow transitive requiredProperty from non default ones

** Improvement
* [ARCHETYPE-624] - scope = provided for artifacts provided by Maven Core

** Dependency upgrade
* [ARCHETYPE-601] - Upgrade to commons-lang 3.8.1
* [ARCHETYPE-615] - Upgrade maven-artifact-transfer to 0.13.1

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: Roadmap for Maven 4/5 (POM 5.0.0)

[Hervé BOUTEMY]

Hi Jimisola,

Did you see https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html

Regards,

Hervé

Le vendredi 17 décembre 2021, 18:17:17 CET Jimisola Laursen a écrit :
> Hi,
> 
> I've been trying to find a roadmap or similar for Maven itself with actual
> dates as there as several things in POM 5.0.0 that we are hoping for
> (mixins most importantly).
> 
> Is there a roadmap with a planned release schedule for Maven 4/5?
> 
> Here is one for Maven Corehttps://
> cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=65875544#conten
> t/view/30741918
> 
> 
> And here is a page on POM Model Version 5.0.0:
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=6587554
> 4#content/view/65875544
> 
> Regards,
> Jimisola





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Wrapper 3.1.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Wrapper, version 3.1.0.

The Maven Wrapper is an easy way to ensure a user of your Maven build has 
everything necessary to run your Maven build.

This is the first release of this project in its Apache Maven new home: it was 
previously maintained by community at https://github.com/takari/maven-wrapper 
and was kindly donated to the Maven team. Thank you to all people who permitted 
this.

See https://maven.apache.org/wrapper/ for instructions on how to use this 
updated Maven Wrapper.

You can download the appropriate sources etc. from the download page:

https://maven.apache.org/wrapper/download.cgi


Release Notes - Maven Wrapper - Version 3.1.0

** Bug
* [MWRAPPER-18] - using MVNW_REPOURL, wrong Maven version is downloaded
* [MWRAPPER-19] - maven-wrapper DefaultDownloader does not parse 
user/password correctly
* [MWRAPPER-20] - Maven Wrapper creates empty file when it fails behind 
proxy 407
* [MWRAPPER-22] - maven-wrapper on windows
* [MWRAPPER-25] - fix installer messages
* [MWRAPPER-37] - restore MVNW_REPOURL support for wrapper plugin

** New Feature
* [MWRAPPER-28] - add mvnwDebug* scripts

** Improvement
* [MWRAPPER-24] - mvnw calls which(1) which is an external command
* [MWRAPPER-27] - rework mvnw* scripts to better match mvn* from Maven 3.8
* [MWRAPPER-29] - Project should build successfully with verify lifecycle
* [MWRAPPER-30] - Add help mojo
* [MWRAPPER-31] - Get rid of maven-artifact-transfer
* [MWRAPPER-32] - Use Maven core component in provided scope

** Wish
* [MWRAPPER-26] - install binary by default to match older user experience

** Task
* [MWRAPPER-14] - Make maven wrapper functional
* [MWRAPPER-17] - IP-CLEARANCE for Maven Wrapper
* [MWRAPPER-34] - use Java 7 for maven-wrapper-plugin and maven-wrapper.jar
* [MWRAPPER-35] - don't copy mvnwDebug* scripts by default


Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Fluido Skin 1.10.0 released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Maven 
Fluido Skin, version 1.10.0.

https://maven.apache.org/skins/maven-fluido-skin/

You should specify the version in your project's site configuration:


   org.apache.maven.skins
   maven-fluido-skin
   1.9



Release Notes - Maven Fluido Skin - Version 1.10.0

** Improvement
* [MSKINS-165] - Inconsistent parent pom in IT tests. 
* [MSKINS-167] - Add deep anchors to headers
* [MSKINS-168] - Switch Minification Engine from YUI to CLOSURE


Enjoy,

-The Apache Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Artifact Plugin 3.2.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Artifact 
Plugin, version 3.2.0

This plugins provides tools to manage artifacts tasks.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.2.0



Release Notes - Apache Maven Artifact Plugin - Version 3.2.0

Bug
* [MARTIFACT-26] karaf-maven-plugin cause buildinfo FileNotFoundException
* [MARTIFACT-23] StringIndexOutOfBoundsException with Java 16 on reproducible 
buildinfo
* [MARTIFACT-19] add quote to reference values in buildinfo.compare

Improvement
* [MARTIFACT-29] add support for pom generated by flatten-maven-plugin
* [MARTIFACT-28] warn if project.build.outputTimestamp has not been defined in 
reactor but in independent parent
* [MARTIFACT-27] warn if project.build.outputTimestamp property has not been 
set
* [MARTIFACT-25] add .pom to the output files being verified

New Feature
* [MARTIFACT-20] create artifact:compare goal (extracted from 
artifact:buildinfo)
* [MARTIFACT-17] add a fail fast option for multi-module

Task
* [MARTIFACT-22] display if current env does not match reference env
* [MARTIFACT-21] rename .buildinfo.compare file to .buildcompare


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need help for maven site plugin for Apache Helix

[Hervé BOUTEMY]

FYI, on the "SiteToolException: Error parsing site descriptor: TEXT must 
beimmediately followed by END_TAG and not START_TAG" error, the key Maven Site 
Plugin version is version 3.5, where the parsing of site.xml changed: 
previously it was parser as XML, and since 3.5 it is parsed as text

the consequence is that in general, you need to surround head and footer data 
from site.xml (including parents) with 

that's why Apache parent version is related to maven-site-plugin version

HTH

Hervé

Le samedi 20 novembre 2021, 09:19:41 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> Apache parent 13 is so old...
> 
> see https://github.com/apache/helix/pull/1909
> upgrading both Apache parent POM and maven-site-plugin seems to do the job
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> > Hi,
> > 
> > I was trying to deploy Apache Helix project website for new releases. Got
> > exception on
> > 
> > *SiteToolException: The site descriptor cannot be resolved from the
> > repository: ArtifactResolutionException: Unable to locate site descriptor:
> > Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> > mvnrepository.com <http://mvnrepository.com> (https://mvnrepository.com
> > <https://mvnrepository.com>): Access denied to:
> > https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
> > <https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml> ,
> > ReasonPhrase:Forbidden.*
> > 
> > [*ERROR*] *  org.apache:apache:xml:13*
> > 
> > [*ERROR*]
> > 
> > [*ERROR*] *from the specified remote repositories:*
> > 
> > [*ERROR*] *  restlet.talend.com <http://restlet.talend.com>
> > (https://maven.restlet.talend.com <https://maven.restlet.talend.com>,
> > releases=true, snapshots=false),*
> > 
> > [*ERROR*] *  mvnrepository.com <http://mvnrepository.com>
> > (https://mvnrepository.com <https://mvnrepository.com>, releases=true,
> > snapshots=false),*
> > 
> > [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> > <https://repo.maven.apache.org/maven2>, releases=true, snapshots=false),*
> > 
> > [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> > <http://repository.apache.org/snapshots>, releases=false, snapshots=true)*
> > 
> > 
> > Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> > It got error on parsing:
> > 
> > *SiteToolException: Error parsing site descriptor*: TEXT must be
> > immediately followed by END_TAG and not START_TAG (position: START_TAG
> > seen
> > ...\n  

Re: Need help for maven site plugin for Apache Helix

[Hervé BOUTEMY]

Hi,

Apache parent 13 is so old...

see https://github.com/apache/helix/pull/1909
upgrading both Apache parent POM and maven-site-plugin seems to do the job

Regards,

Hervé

Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> Hi,
> 
> I was trying to deploy Apache Helix project website for new releases. Got
> exception on
> 
> *SiteToolException: The site descriptor cannot be resolved from the
> repository: ArtifactResolutionException: Unable to locate site descriptor:
> Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> mvnrepository.com  (https://mvnrepository.com
> ): Access denied to:
> https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
>  ,
> ReasonPhrase:Forbidden.*
> 
> [*ERROR*] *  org.apache:apache:xml:13*
> 
> [*ERROR*]
> 
> [*ERROR*] *from the specified remote repositories:*
> 
> [*ERROR*] *  restlet.talend.com 
> (https://maven.restlet.talend.com ,
> releases=true, snapshots=false),*
> 
> [*ERROR*] *  mvnrepository.com 
> (https://mvnrepository.com , releases=true,
> snapshots=false),*
> 
> [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> , releases=true, snapshots=false),*
> 
> [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> , releases=false, snapshots=true)*
> 
> 
> Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> It got error on parsing:
> 
> *SiteToolException: Error parsing site descriptor*: TEXT must be
> immediately followed by END_TAG and not START_TAG (position: START_TAG seen
> ...\n  

Re: Can not use a snapshot version in parent

[Hervé BOUTEMY]

can you please share the xxx part of your pom.xml, 
please?

and look at logs of "mvn -X", to see precisely what urls are fetched?

Regards,

Hervé

Le samedi 2 octobre 2021, 10:58:14 CEST Martin Aldrin a écrit :
> Hi, thanks for the anser.
> 
> 1. We have used this format for years in our CI. And it works perfect for
> all other dependencies.
> 
> 2. Yes, the artifact exist on our nexus server. And it works perfect if I
> first fetch it to my local repository.
> 
> Regards
> /Martin
> 
> > On 2 Oct 2021, at 09:53, Hervé BOUTEMY  wrote:
> > 
> > Hi Martin,
> > 
> > I'm replying to users@maven.apache.org because iss...@maven.apache.org is
> > not a mailing list where anybody answers :)
> > 
> > Looking at the log, I see "Could not find artifact com.x.commonlibrary:cl-
> > parent:pom:1.5.39-20210922124845805-SNAPSHOT"
> > 
> > It seems you referenced parent POM as "1.5.39-20210922124845805-SNAPSHOT"
> > when:
> > 1. you should not add the "-SNAPSHOT" suffix but
> > "1.5.39-20210922124845805": Maven detects that the suffix represents a
> > SNAPSHOT
> > 2. are you sure of your "-20210922124845805" value, as it is represented
> > in
> > your repository? With usual format (that I think is the only one
> > supported), it should be "-20210922.124845-805"
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 1 octobre 2021, 13:46:42 CEST mar...@aldrin.net a écrit :
> >> Hi,
> >> My problem is that I want to test uplift our parent on 400 project to
> >> test
> >> the combability with Java 17 without releasing the new parent. It works
> >> perfect for regular releases, but not if I using a snapshot with time
> >> prefix. Do any one have a idea if this can be solved in any way or if I'm
> >> doing something wrong. It works if first trigger a download of the
> >> snapshot
> >> artifact, but I don't want to do that manually on all different servers,
> >> I
> >> hope the snapshot could be downloaded automatically as it works for
> >> regular
> >> dependencies.
> >> 
> >> 
> >> 
> >> mvn -U help:evaluate -f pom.xml -Dexpression=project.properties
> >> Exit Code: 1[Pipeline]ech)Warning: A secret was passed to "echo" using
> >> Groovy String interpolation, which is insecure. Affected argument(s) used
> >> the following variable(s):[FUNCTIONAL_CRED_USR]
> >> See[<https://jenkins.io/redirect/groovy-string-interpolatio>|<https://jen
> >> ki
> >> ns.io/redirect/groovy-string-interpolation]n> for details. Output: -
> >> withMaven Wrapper script -
> >> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> >> Maven home: /app/vbuild/tools/maven/3.6.3
> >> Java version: 17, vendor: Azul Systems, Inc., runtime:
> >> /app/openjdk/17.0.0
> >> Default locale: en_US, platform encoding: ISO-8859-1
> >> OS name: "linux", version: "3.10.0-1127.el7.x86_64", arch: "amd64",
> >> family:
> >> "unix" [INFO][jenkins-event-spy]Generate
> >> maven-spy-20210923-121848-99516578763949166347886.log.tmp ...
> >> [INFO]Scanning for projects...[ERROR][ERROR]Some problems were
> >> encountered
> >> while processing the POMs:[FATAL]Non-resolvable parent POM for
> >> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT: Could not find
> >> artifact
> >> com.x.commonlibrary:cl-parent:pom:1.5.39-20210922124845805-SNAPSHOT and
> >> 'parent.relativePath' points at wrong local POM @ line 9, column 13 @
> >> [INFO][jenkins-event-spy]Generated
> >> maven-spy-20210923-121848-99516578763949166347886.log[ERROR]The build
> >> could
> >> not read 1 project ->[Help 1][ERROR][ERROR]The project
> >> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT /proj/cl1/pom.xml)
> >> has 1 error[ERROR]Non-resolvable parent POM for
> >> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT: Could not find
> >> artifact
> >> com.x.commonlibrary:cl-parent:pom:1.5.39-20210922124845805-SNAPSHOT and
> >> 'parent.relativePath' points at wrong local POM @ line 9, column 13
> >> ->[Help
> >> 2][ERROR][ERROR]To see the full stack trace of the errors, re-run Maven
> >> with the -e switch.[ERROR]Re-run Maven using the -X switch to enable full
> >> debug logging.[ERROR][ERROR]For more information about the errors and
> >> possible solutions, please read the following articles:[ERROR][Help
> >> 1][<http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingExcep
> >> ti
> >> o>|<http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingExcep
> >> tio n]n[ERROR>][Help
> >> 2][<http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelExc
> >> ep
> >> tio>|<http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelE
> >> xce ption]n>





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can not use a snapshot version in parent

[Hervé BOUTEMY]

Hi Martin,

I'm replying to users@maven.apache.org because iss...@maven.apache.org is not 
a mailing list where anybody answers :)

Looking at the log, I see "Could not find artifact com.x.commonlibrary:cl-
parent:pom:1.5.39-20210922124845805-SNAPSHOT"

It seems you referenced parent POM as "1.5.39-20210922124845805-SNAPSHOT" 
when:
1. you should not add the "-SNAPSHOT" suffix but "1.5.39-20210922124845805": 
Maven detects that the suffix represents a SNAPSHOT 
2. are you sure of your "-20210922124845805" value, as it is represented in 
your repository? With usual format (that I think is the only one supported), 
it should be "-20210922.124845-805"

Regards,

Hervé

Le vendredi 1 octobre 2021, 13:46:42 CEST mar...@aldrin.net a écrit :
> Hi,
> My problem is that I want to test uplift our parent on 400 project to test
> the combability with Java 17 without releasing the new parent. It works
> perfect for regular releases, but not if I using a snapshot with time
> prefix. Do any one have a idea if this can be solved in any way or if I'm
> doing something wrong. It works if first trigger a download of the snapshot
> artifact, but I don't want to do that manually on all different servers, I
> hope the snapshot could be downloaded automatically as it works for regular
> dependencies.
> 
> 
> 
> mvn -U help:evaluate -f pom.xml -Dexpression=project.properties
> Exit Code: 1[Pipeline]ech)Warning: A secret was passed to "echo" using
> Groovy String interpolation, which is insecure. Affected argument(s) used
> the following variable(s):[FUNCTIONAL_CRED_USR]
> See[| ns.io/redirect/groovy-string-interpolation]n> for details. Output: -
> withMaven Wrapper script -
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /app/vbuild/tools/maven/3.6.3
> Java version: 17, vendor: Azul Systems, Inc., runtime: /app/openjdk/17.0.0
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux", version: "3.10.0-1127.el7.x86_64", arch: "amd64", family:
> "unix" [INFO][jenkins-event-spy]Generate
> maven-spy-20210923-121848-99516578763949166347886.log.tmp ...
> [INFO]Scanning for projects...[ERROR][ERROR]Some problems were encountered
> while processing the POMs:[FATAL]Non-resolvable parent POM for
> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT: Could not find
> artifact
> com.x.commonlibrary:cl-parent:pom:1.5.39-20210922124845805-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 9, column 13 @
> [INFO][jenkins-event-spy]Generated
> maven-spy-20210923-121848-99516578763949166347886.log[ERROR]The build could
> not read 1 project ->[Help 1][ERROR][ERROR]The project
> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT /proj/cl1/pom.xml)
> has 1 error[ERROR]Non-resolvable parent POM for
> com.x.commonlibrary:test-suite-editor:0.2.115-SNAPSHOT: Could not find
> artifact
> com.x.commonlibrary:cl-parent:pom:1.5.39-20210922124845805-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 9, column 13 ->[Help
> 2][ERROR][ERROR]To see the full stack trace of the errors, re-run Maven
> with the -e switch.[ERROR]Re-run Maven using the -X switch to enable full
> debug logging.[ERROR][ERROR]For more information about the errors and
> possible solutions, please read the following articles:[ERROR][Help
> 1][ o>| n]n[ERROR>][Help
> 2][ tio>| ption]n>





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven WAR Plugin, version 3.3.2

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven WAR 
Plugin, version 3.3.2

This plugin builds a Web Application Archive (WAR) file from the project output 
and its dependencies.

https://maven.apache.org/plugins/maven-war-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-war-plugin
  3.3.2



Release Notes - Apache Maven WAR Plugin - Version 3.3.2

Bug
* [MWAR-439] WAR Plugin 3.3.1 hits NPE when exploding if maven session start 
time is null

Improvement
* [MWAR-441] Allow "outdatedCheckPath" parameter to be set to cover web app 
dir root (everything in the web app directory)


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Software Foundation Parent POM Version 24 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Software 
Foundation Parent POM Version 24.

https://maven.apache.org/pom/asf/

You should specify the version in your project as parent like the following:


   org.apache
   apache
   24


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/pom/asf/download.html

Release Notes - Maven POMs - Version ASF-24

** Improvement
* [MPOM-238] - configure site-deploy for documentation
* [MPOM-240] - upgrade maven-shade-plugin to 3.2.2 to get Reproducible 
Builds for shaded artifacts
* [MPOM-244] - Deploy SHA-512 for source-release to Remote Repository
* [MPOM-247] - Make minimum enforced Maven version configurable via property
* [MPOM-255] - Enforce local property "project.build.outputTimestamp" for 
reproducible builds
* [MPOM-260] - Configure Maven Javadoc Plugin for more reproducible builds
* [MPOM-263] - Enforce building with Java 8+

** Dependency upgrade
* [MPOM-168] - JDK 9 requires updates to plugins
* [MPOM-208] - upgrade m-scm-publish-p
* [MPOM-246] - Upgrade Maven Project Info Reports Plugin to 3.1.1
* [MPOM-248] - Upgrade maven-antrun-plugin to 3.0.0
* [MPOM-249] - Upgrade checksum-maven-plugin 1.9
* [MPOM-251] - Set minimum enforced Maven version to 3.1.1
* [MPOM-256] - Drop org.codehaus.mojo:clirr-maven-plugin
* [MPOM-258] - Upgrade maven-resources-plugin to 3.2.0
* [MPOM-259] - Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
* [MPOM-262] - Require Java 8


Changes since version 23:

https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24#diff

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: Problem with mvn site:run and javadocs

[Hervé BOUTEMY]

Hi,

To me, looking at javadoc or jxr output during "mvn site:run" is not supposed 
to work: "mvn site:run" is here to help write markup for the site, to quickly 
see the output when you update markdown/apt/... source

Why are you trying to use site:run to look at javadoc or jxr?

Notice, whatever the answer is, implementing file by file rendering update as 
required by site:run seems quite hard...
If you want to look at javadoc or jxr, you're expected to run "mvn site" and 
open your browser at target/site/index.html

Regards,

Hervé

Le lundi 28 juin 2021, 20:19:24 CEST Mikhail Titov a écrit :
> Hello all!
> 
> I have the same issue as back from 2009[1]. I'm not sure if it ever
> worked or even supposed to. I thought something is off with my project
> (single pom). However, I see the same issue even if I use maven
> archetype to generate a new one.
> 
> I see that JIRA moved to https://issues.apache.org/jira/browse/MSITE-220
> but the issue was closed in a great purge of 2014. It seems to me that
> it is still an issue unless that is not how javadoc is supposed to be
> used. Please advise.
> 
> In particular, I tried Spring Boot WebSocket Sample. Then I added
> 
> ,[ project/build/plugins ]
> 
> | 
> | 
> |   org.apache.maven.plugins
> |   maven-site-plugin
> |   3.7.1
> | 
> | 
> | 
> | 
> |   org.apache.maven.plugins
> |   maven-project-info-reports-plugin
> |   3.1.1
> | 
> | 
> 
> `
> 
> ,[ project ]
> 
> | 
> | 
> |   
> | 
> | 
> | 
> |   org.apache.maven.plugins
> |   maven-javadoc-plugin
> |   3.3.0
> | 
> | 
> |   
> |   
> | 
> | 
> 
> `
> 
> Now, if I do mvn site:run and navigate to
> http://localhost:8080/apidocs/index.html , then I get
> 
> ,
> 
> | HTTP ERROR 500
> | 
> | Problem accessing /apidocs/index.html. Reason:
> | Error generating maven-javadoc-plugin:3.3.0:aggregate-no-fork report
> | 
> | Caused by:
> | org.apache.maven.doxia.siterenderer.RendererException: Error generating
> | maven-javadoc-plugin:3.3.0:aggregate-no-fork report| 
> | at
> | 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocume
> | nt(ReportDocumentRenderer.java:245) at
> | 
org.apache.maven.plugins.site.run.DoxiaFilter.doFilter(DoxiaFilter.java:
> | 144) at
> | 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHan
> | dler.java:1157) at
> | org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
388)
> | at
> | 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:2
> | 16) at
> | org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
182)
> | at
> | org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
765)
> | at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
440)
> | at
> | 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.jav
> | a:114) at
> | org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
152)
> | at org.mortbay.jetty.Server.handle(Server.java:326)
> | at
> | org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
542)
> | at
> | 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConne
> | ction.java:926) at
> | org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
> | at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> | at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> | at
> | 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
> | 410) at
> | 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java
> | :582)| 
> | Caused by: org.apache.maven.reporting.MavenReportException:
> | Exit code: 1 -
> | C:\tmp\123\arid-spring\src\main\java\samples\websocket\client\SimpleClien
> | tWebSocketHandler.java:21: error: package org.apache.commons.logging does
> | not exist import org.apache.commons.logging.Log;
> | ...
> 
> `
> 
> 
> Footnotes:
> [1]  https://www.mail-archive.com/users@maven.apache.org/msg103216.html
> 
> --
> Mikhail
> 
> -
> 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: apache-source-release-assembly-descriptor does not retain correctly file permissions

[Hervé BOUTEMY]

if you need to have consistent executable flags, you need to avoid getting it 
from filesystem, because it is dependent on OS and user configuration
that's why for example, on such requirements in Maven (core), we use a 
dedicated assembly descriptor instead of the generic one [1]

HTH

Hervé

[1] 
https://github.com/apache/maven/blob/master/apache-maven/src/assembly/maven/component.xml

Le lundi 14 juin 2021, 09:16:57 CEST Enrico Olivelli a écrit :
> Hello,
> It looks like following this guide in order to create a good "source
> bundle" for an ASF Project (in this case Apache Pulsar) leads to a
> strange behaviour.
> https://maven.apache.org/apache-resource-bundles/
> 
> Basically some files miss the 'executable' flag, this way when the
> user unpacks the released sources the build does not work because
> there are scripts that are not executable.
> 
> more context here
> https://github.com/apache/pulsar/issues/10917
> 
> Has anyone had the same experience ?
> 
> Regards
> Enrico
> 
> -
> 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: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Hervé BOUTEMY]

there is a broader plan that tries to be documented at
https://maven.apache.org/developers/compatibility-plan.html

but given each plugin has its own lifecycle, without precise release schedule, 
and voluntary work, it is followed at a "soft" speed

I know that one of my personal dreams on this would to enhance the current 
prerequisites dist-tool report [1], to add prerequisites for older plugins 
releases, to have more precise view of history.
But by lack of interest or help of the general community, this has stayed at 
dream level

Regards,

Hervé

[1] 
https://ci-builds.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-prerequisites.html

Le mercredi 9 juin 2021, 08:42:14 CEST Rick Hanton a écrit :
> Thanks for the help and input Tamas and Ben!
> 
> Yes, I wasn't demanding or expecting anything, just was curious if there
> was some broader "plan", but it sounds like it's up to the individual
> maintainers, which is fine. We too were hoping that our operations folks
> would get all the web application servers upgraded to Java 8 last year,
> which apparently didn't "quite" happen - thus I'm still supporting a few
> servers running [very ancient] versions of Java 1.7. I'll probably have a
> fun meeting with my bosses soon and perhaps I too can just say that no
> longer will any of the libraries I build be Java 1.7 compatible, so if one
> of those clients needs it, they can get their server upgraded or "too bad"
> - man that'd be great!
> 
> Cheers,
> Rick
> 
> E-mail: hant...@gmail.com
> Twitter: rack88 
> 
> 
> On Tue, Jun 8, 2021 at 12:31 PM Benjamin Marwell 
> 
> wrote:
> > Just FYI,
> > 
> > IBM, Zulu, Oracle and Microsoft are giving extended support to paying
> > customers until the 2030s. I guess maven plugins will stay on 1.8 for
> > quite
> > a while, but that's just a guess.
> > At least most libraries haven't moved to Java 11 yet (and afaik won't move
> > to Java 11 in the near future).
> > 
> > There is no extended support available for Java 7 from most vendors (maybe
> > Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
> > unusable. I doubt that there is a good reason to support Java 1.7 now.
> > Updating to Java 8 shouldn't be a big issue and will get you quite some
> > performance gains.
> > 
> > HTH
> > Ben
> > 
> > On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:
> > > Howdy,
> > > 
> > > Let me state several things in advance first:
> > > - ASF Maven project (the project) is an open source project maintained
> > > by
> > > volunteers in their spare time.
> > > - We (as a project) do not provide any kind of "support" or any of that
> > > stuff.
> > > 
> > > That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and
> > > yes,
> > > we try to move to supported (read: freely available) Java versions.
> > > 
> > > Hence, if you are stuck on Java 7, your best option is really to "lock
> > > down" your plugin versions as well, and accept the fact that you are
> > 
> > stuck
> > 
> > > on your tooling as well.
> > > 
> > > We, as a Java project, have upstream dependencies, and time is pressing
> > 
> > us
> > 
> > > also, as more and more projects move to Java 8 (if not to Java 11), that
> > 
> > in
> > 
> > > the same way prevents us from consuming the latest dependencies, hence,
> > 
> > the
> > 
> > > whole "flock" (ecosystem) has to follow the moving target.
> > > 
> > > So, while there is no "general guideline" (aside that Maven CLI 3.x is
> > 
> > Java
> > 
> > > 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins
> > > in
> > > ASF and outside) and plugin version numbers being "unbounded" (are per
> > > plugins, not really bounded to Maven CLI), we try our best when we
> > > switch
> > > plugin from Java 7 to something higher; it usually means minor or major
> > > version update (so will not happen in a "patch release"), and pretty
> > > much
> > > always will be present in release notes, just like it is in case of
> > > maven-javadoc-plugin:
> > > https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
> > > 
> > > So, it is up to you to search thru release notes, and figure out which
> > > plugin requires which version of Java.
> > > 
> > > HTH
> > > Tamas
> > > 
> > > On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
> > > > Hi folks,
> > > > 
> > > > Just wondering if someone can point me to any documentation about one
> > 
> > of
> > 
> > > > the following things:
> > > > 
> > > > 1) Is there a high level direction among apache projects and
> > 
> > particularly
> > 
> > > > apache maven plugin projects to no longer build using the version 1.7
> > > 
> > > JDK?
> > > 
> > > > I'm seeing similar changes to move away from Java 7 as I poke through
> > > 
> > > some
> > > 
> > > > projects like Surefire and maven-javadoc-plugin's latest
> > 
> > builds/releases.
> > 
> > > > This is creating some chaos for my company, where we typically use the
> > > > maven-release 

[ANN] Apache Maven Artifact Plugin 3.1.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Artifact 
Plugin, version 3.1.0

Plugin to manage artifacts tasks

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.1.0



Release Notes - Apache Maven Artifact Plugin - Version 3.1.0

Bug
* [MARTIFACT-13] NPE when checking a jar that has no META-INF/maven/groupId/
artifactId/pom.properties

New Feature
* [MARTIFACT-18] add reference OS and java version to .buildinfo.compare
* [MARTIFACT-15] add diffoscope commands to .buildinfo.compare output
* [MARTIFACT-14] add an option to generate reproducible .buildinfo file 
(removing detailed environment data)

Task
* [MARTIFACT-16] add pgpverify check to the build


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin execution order in same phase + profiles

[Hervé BOUTEMY]

looking at its code, it seems it uses LifecycleExecutor [1]

I don't know implementation details, if it has edge cases, but I suppose this 
will bring the same result as what Maven core will execute

Regards,

Hervé

[1] 
https://maven.apache.org/ref/3.8.1/maven-core/apidocs/org/apache/maven/lifecycle/LifecycleExecutor.html

Le lundi 10 mai 2021, 11:14:12 CEST Nick Stolwijk a écrit :
> Hervé,
> 
> > What you can also do is look at "mvn help:effective-pom -Dverbose" also
> 
> to see
> 
> > the result without executing
> 
> Do you know if the order that shows with `mvn
> fr.jcgay.maven.plugins:buildplan-maven-plugin:list`[1] is also the
> guaranteed* execution order?
> 
> * guaranteed for that Maven version and activated profiles
> 
> [1] https://github.com/jcgay/buildplan-maven-plugin
> 
> With regards,
> 
> Nick Stolwijk
> 
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
> 
> Lord Baden-Powell
> 
> On Fri, May 7, 2021 at 7:56 AM Hervé BOUTEMY  wrote:
> > > Can anybody enlighten me on what is happening here and if this behaviour
> > > is documented anywhere? Or is this just the "read the freakin' source
> > > code, pal" kind of detail?
> > 
> > order in the same phase is not expected to be guaranteed: that's a design
> > choice (even if "choice" is not the best term IMHO: see below).
> > Then there can't be any formal documentation: it's just what it is on each
> > Maven release (and maybe has changed over time).
> > see https://issues.apache.org/jira/browse/MNG-5987
> > 
> > On design "choice":
> > I worked on it in the past to see if we could change that "choice", and
> > it's
> > more complex than what people think:
> > - impact of profile injection, and if you want to control order, key
> > question:
> > in your case, do you prefer injecting profile-defined plugins before or
> > after?
> > - mix of plugins/goals and executions: in fact, we talk about plugins
> > order,
> > but what you need is goal execution order. And de-facto, given multiple
> > goals
> > executions are associated to one unique plugin definition during model
> > building
> > (that one is a design decision), you can't influence order at goal
> > execution
> > level but only full plugin
> > 
> > You can read Model Builder documentation and code if you want, this is
> > where
> > you'll find the details:
> > https://maven.apache.org/ref/current/maven-model-builder/
> > But stability over multiple Maven version remains not guaranteed.
> > 
> > 
> > 
> > HTH
> > 
> > Hervé
> > 
> > Le vendredi 7 mai 2021, 01:13:53 CEST Alexander Kriegisch a écrit :
> > > I notices an unexpected thing about plugin execution order: If I have
> > > several plugins running in the same phase, normally they are executed in
> > > the lexical order in which they appear in the POM. But there is a case
> > > in which this can change. Schematically, it looks like this:
> > > 
> > > 
> > > 
> > >   
> > >   
> > > 
> > > 
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > > 
> > >   
> > >   
> > > 
> > > 
> > > 
> > > 
> > > 
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > > 
> > > 
> > > My expectation was that the execution order in phase X would be plugin
> > > A, then B. This is true sometimes, depending on which build other
> > > profiles are active. I mean completely unrelated profiles defined in
> > > other Maven modules. In my specific case, without specifying any other
> > > profiles (P is auto-activated bases on non-existence of a file), the
> > > order was B, A. If I manually activated any other profile or
> > > de-activated a profile which otherwise would be active automatically,
> > > the order changed to A, B.
> > > 
> > > In my case, I had the option of moving plugin B to a later phase, which
> > > settled the issue for me, but that is not always possible.
> > > 
> > > Can anybody enlighten me on what is happening here and if this behaviour
> > > is documented anywhere? Or is this just the "read the freakin' source
> > > code, pal" kind of detail?
> > 
> > -
> > 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: Plugin execution order in same phase + profiles

[Hervé BOUTEMY]

Le dimanche 9 mai 2021, 07:52:21 CEST Alexander Kriegisch a écrit :
> Hervé BOUTEMY schrieb am 09.05.2021 03:31 (GMT +07:00):
> > Le samedi 8 mai 2021, 17:03:05 CEST Alexander Kriegisch a écrit :
> >> My question was how to achieve reliably predictable ordering. That
> >> question is yet to be answered.
> > 
> > it is answered: you currently can't.
> 
> Actually, your first reply sounded like you explained some technical
> background to me and wanted me to figure out the rest by myself.
ok, I tried to be short and clear in the first paragraph, but I failed :)

> I did
> not read it as "you currently cannot", my apologies. But actually, the
> workaround Delaney sketched in his answer sounds viable. Would you
> agree?
Delany found a smart workaround to try to have full control about order in 
effective POM, then on build plan: nice idea, even if cumbersome
If you don't play too much with profiles, inheritance, and don't expect too 
much control at execution level (instead of plugin), I suppose our effective 
POM building algorithm should not change the order in the future.
Then you're still playing at your own risk with implementation details, but it 
may work sufficiently well.

> 
> >> I am afraid (...) the thread will just trickle out. (...) my PR for
> >> Maven Shade Plugin which did not get a single reaction, even though
> >> it fixes an old problem, adding new functionality. But maybe I just
> >> need to be more patient. :-)
> > 
> > if you want to work with me, I'll be available on May 29th during Hack
> > Commit Push to hack together on Maven:
> > https://paris2021.hack-commit-pu.sh/#projects
> 
> Actually, that would be awesome. I just cannot say if I can make it,
> because I have a quite demanding daytime job as an Agile Coach too and
> only program in my sparetime as a hobby.
same here you know for every Maven committers

> Furthermore, I am currently
> working in time zone Southeast Asia. But thanks for the invitation, I
> might register and participate if I can.
don't hesitate to join only a few hours: having a small human interaction and 
discussion helps when we are between hobbyists

> Actually though, I would prefer
> raised issues and PRs being worked on independently of my participation
> in such an event. I know that would be slower due to the asynchronicity,
> if we need to discuss the PR, but at least possible. I hope we can get
> that thing off the table and into Maven Shade the usual way, too. I
> certainly did my share of work, commenting on issues and preparing a PR,
> and I am willing to assist in any other way I can, promising to be
> responsive whenever you ask something.
Maven Shade Plugin is not part of the plugins I usually work on. Please put 
the link to your PR, I can add it to my already long personal TODO list and 
see if I have some spare time

Regards,

Hervé

> 
> Regards





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven GPG Plugin 3.0.1 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven GPG 
Plugin, version 3.0.1

Signs the project artifacts with GnuPG.

https://maven.apache.org/plugins/maven-gpg-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-gpg-plugin
  3.0.1



Release Notes - Apache Maven GPG Plugin - Version 3.0.1

Bug
* [MGPG-81] GPGVersion.compareTo misuses IllegalArgumentException 
* [MGPG-79] plugin hangs on first run on Windows Git Bash with Kleopatra
* [MGPG-78] gpg version parsing failure on Windows
* [MGPG-66] sign goal's "excludes" configuration ignored

Task
* [MGPG-80] GPGVersion compareTo is not consistent with equals


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin execution order in same phase + profiles

[Hervé BOUTEMY]

Le samedi 8 mai 2021, 17:03:05 CEST Alexander Kriegisch a écrit :
> Nooo! I don't need extra phases, nor do I have any desire to create
> custom lifecycles, even though I know this is possible. My point was: If
> we cannot rely on a specific order when executing plugins and executions
> within them in the same phase, the logical consequence for deterministic
> behaviour would be one phase per plugin or execution. That would be
> overkill to the 5th power. My question was how to achieve reliably
> predictable ordering. That question is yet to be answered.
it is answered: you currently can't

> 
> I am afraid, just like with the last question I asked here (about the
> dependency-reduced POM ), in the end I am not going to get a conclusive
> answer and the thread will just trickle out. Or with my PR for Maven
> Shade Plugin which did not get a single reaction, even though it fixes
> an old problem, adding new functionality. But maybe I just need to be
> more patient. :-)
if you want to work with me, I'll be available on May 29th during Hack Commit 
Push to hack together on Maven
https://paris2021.hack-commit-pu.sh/#projects

Regards,

Hervé

> 
> To everyone who already replied to me, thank you so much for helping me
> understand some things better.
> 
> > Hi. In case you really need custom phases, it is possible to add them. See
> > https://github.com/raydac/mvn-finisher for an example for adding new
> > phases. But I would say this is the last resort in case no other solutions
> > work for you.
> > 
> > la 8. toukok. 2021 klo 10.40 Alexander Kriegisch
> > (alexan...@kriegisch.name)
> > 
> > kirjoitti:
> >> >> Can anybody enlighten me on what is happening here and if this
> >> >> behaviour is documented anywhere? Or is this just the "read the
> >> >> freakin' source code, pal" kind of detail?
> >> > 
> >> > order in the same phase is not expected to be guaranteed: that's a
> >> > design choice (even if "choice" is not the best term IMHO: see below).
> >> > Then there can't be any formal documentation: it's just what it is on
> >> > each Maven release (and maybe has changed over time). see
> >> > https://issues.apache.org/jira/browse/MNG-5987
> >> 
> >> IMO, that is a very unfortunate "design choice", complex situation or or
> >> not. Because if you want to order plugins, in theory you would need a
> >> separate phase for each. But phases in a lifecycle are limited.
> >> 
> >> > - impact of profile injection, and if you want to control order, key
> >> > question: in your case, do you prefer injecting profile-defined
> >> > plugins before or after?
> >> 
> >> It is not so much about what I prefer. It is about it being
> >> deterministic with clear, documented, release-stable rules. I could
> >> adjust my POM to whatever those hypothetical rules would say.
> >> 
> >> > - mix of plugins/goals and executions: in fact, we talk about plugins
> >> > order, but what you need is goal execution order. And de-facto, given
> >> > multiple goals executions are associated to one unique plugin
> >> > definition during model building
> >> 
> >> Actually, I want both, to determine the order of executions within the
> >> same phase within the same plugin as well as the execution order of
> >> sifferent plugins in the same phase. But my described use case here was
> >> the latter, i.e. the problem really is about two different plugins.
> >> 
> >> To make a long story short: My use case is a valid one, and many users
> >> face the same situation. What does the Maven team recommend? How is this
> >> to be handled in a canonical way? Just saying "you cannot rely on it"
> >> does not solve the problem.
> >> 
> >> > Le vendredi 7 mai 2021, 01:13:53 CEST Alexander Kriegisch a écrit :
> >> >> I notices an unexpected thing about plugin execution order: If I have
> >> >> several plugins running in the same phase, normally they are executed
> >> >> in
> >> >> the lexical order in which they appear in the POM. But there is a case
> >> >> in which this can change. Schematically, it looks like this:
> >> >> 
> >> >> 
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >>   
> >> >>   
> >> >> 
> >> >> 
> >> >> 
> >> >> My expectation was that the execution order in phase X would be plugin
> >> >> A, then B. This is true sometimes, depending on which build other
> >> >> profiles are active. I mean completely unrelated profiles defined in
> >> >> other Maven modules. In my specific case, without specifying any other
> >> >> profiles (P is auto-activated bases on non-existence of a file), the
> >> >> order was B, A. If I manually activated any other profile or
> >> >> de-activated a profile which otherwise would be active automatically,
> >> >> the order changed to A, B.
> >> >> 
> >> >> In my case, I had the option of moving 

Re: Plugin execution order in same phase + profiles

[Hervé BOUTEMY]

> Can anybody enlighten me on what is happening here and if this behaviour
> is documented anywhere? Or is this just the "read the freakin' source
> code, pal" kind of detail?
order in the same phase is not expected to be guaranteed: that's a design 
choice (even if "choice" is not the best term IMHO: see below).
Then there can't be any formal documentation: it's just what it is on each 
Maven release (and maybe has changed over time).
see https://issues.apache.org/jira/browse/MNG-5987

On design "choice":
I worked on it in the past to see if we could change that "choice", and it's 
more complex than what people think:
- impact of profile injection, and if you want to control order, key question: 
in your case, do you prefer injecting profile-defined plugins before or after?
- mix of plugins/goals and executions: in fact, we talk about plugins order, 
but what you need is goal execution order. And de-facto, given multiple goals 
executions are associated to one unique plugin definition during model building 
(that one is a design decision), you can't influence order at goal execution 
level but only full plugin

You can read Model Builder documentation and code if you want, this is where 
you'll find the details:
https://maven.apache.org/ref/current/maven-model-builder/
But stability over multiple Maven version remains not guaranteed.

What you can also do is look at "mvn help:effective-pom -Dverbose" also to see 
the result without executing

HTH

Hervé

Le vendredi 7 mai 2021, 01:13:53 CEST Alexander Kriegisch a écrit :
> I notices an unexpected thing about plugin execution order: If I have
> several plugins running in the same phase, normally they are executed in
> the lexical order in which they appear in the POM. But there is a case
> in which this can change. Schematically, it looks like this:
> 
> 
>   
> 
>   
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> My expectation was that the execution order in phase X would be plugin
> A, then B. This is true sometimes, depending on which build other
> profiles are active. I mean completely unrelated profiles defined in
> other Maven modules. In my specific case, without specifying any other
> profiles (P is auto-activated bases on non-existence of a file), the
> order was B, A. If I manually activated any other profile or
> de-activated a profile which otherwise would be active automatically,
> the order changed to A, B.
> 
> In my case, I had the option of moving plugin B to a later phase, which
> settled the issue for me, but that is not always possible.
> 
> Can anybody enlighten me on what is happening here and if this behaviour
> is documented anywhere? Or is this just the "read the freakin' source
> code, pal" kind of detail?





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Release of maven-gpg-plugin

[Hervé BOUTEMY]

ok, I'll try againt to do a release: I hope users tested during that year, so 
I won't have to cancel the vote again...

Regards,

Hervé

Le mercredi 5 mai 2021, 15:02:10 CEST Konrad Windszus a écrit :
> Hi,
> the current release 1.6 is from 2015 and I am suffering from
> https://issues.apache.org/jira/browse/MGPG-66
>  which has been fixed in
> MGPG-66. Currently there are no open issues for the upcoming release 3.0.1
> (https://issues.apache.org/jira/projects/MGPG/versions/12348086
> ).
> 
> The last release attempt 3.0 has been cancelled last April due to
> https://issues.apache.org/jira/browse/MGPG-78
>  (fixed meanwhile) and there
> has been no further release candidate. More than one year later it would be
> great to see a new release.
> 
> Thanks in advance,
> Konrad





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: https://www.mojohaus.org is down?

[Hervé BOUTEMY]

I just fixed it

https://github.com/mojohaus/versions-maven-plugin/issues/458

Regards,

Hervé

Le jeudi 29 avril 2021, 22:25:23 CEST Niels Basjes a écrit :
> Hi,
> 
> Just now I wanted to lookup the documentation for the versions-maven-plugin
> yet I found that website https://www.mojohaus.org/versions-maven-plugin/ to
> be offline (or more precise: I get a github error).
> 
> I have no clue where to report this (other than this mailing list).





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven superpom, JUnit 5 and Spring

[Hervé BOUTEMY]

yes, as Tibor says, with Maven 4 we'll start to move the default plugins 
versions in each Maven release (which we did not do before to keep stability, 
even if stability consequence is "old versions defined years ago")

which leads even more to the first answer:
In other words, do not rely on the implied Super Parent Pom for defining plugin 
versions because it will not guarantee build stability.  Instead, your pom 
hierarchy should explicitly declare the plugin versions to use.

which leads to the whole discussion on how to manage easily and with stability 
plugins versions (through Corporate parent as a first level of answer, though 
wanted future pluginManagement import feature)

Notice: I use "stability" term, because nowadays "reproducibility" is more 
"owned" by "Reproducible Builds"

Regards,

Hervé

Le lundi 8 mars 2021, 00:52:41 CET Tibor Digana a écrit :
> shortly, the Maven 3.7.0 had the Jira issue, and I think resolved it, with
> bumped versions of default plugins to the most recent ones.
> We stopped 3.7.0 and we are developing 4.0.0 now.
> T
> 
> On Sun, Mar 7, 2021 at 10:58 PM Greg Chabala  wrote:
> > You're taking the discussion to a place about building something flexible,
> > but the initial question from a user was 'Why is the Super POM pulling in
> > an old version of maven-surefire-plugin by default?'. That's an issue that
> > deserves to be solved.
> > 
> > Maven 3.6.3's Super POM pulls in maven-surefire-plugin version 2.12.4,
> > which was published 2012-09-24. Can we update the Super POM to something
> > less ancient so that new users don't get burned by default?
> > 
> > On Sun, Mar 7, 2021 at 2:07 PM Hervé BOUTEMY 
> > 
> > wrote:
> > > if you're talking about the little subset that we use for our default
> > > packaging bindings [1], as you can see from the page, there is already a
> > > version fixed by the bindings
> > > 
> > > but:
> > > 1. that ties you to a precise Maven version, which is something we want
> > 
> > to
> > 
> > > avoid
> > > 2. it does not work for the many other plugins
> > > 
> > > that's why any discussion is about making something flexible, and not
> > > focusing
> > > only on the few plugins used by default packagings
> > > 
> > > regards,
> > > 
> > > Hervé
> > > 
> > > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> > > 
> > > Le dimanche 7 mars 2021, 15:43:45 CET Mantas Gridinas a écrit :
> > > > Maven does not provide all of those 5 thousand plugins by default,
> > > > does
> > > 
> > > it?
> > > 
> > > > On Sun, Mar 7, 2021 at 11:39 AM Hervé BOUTEMY 
> > > 
> > > wrote:
> > > > > > But my question is why not add a feature where maven would
> > > > > > produce a pom that contains the default plugins, repositories, and
> > > 
> > > etc.
> > > 
> > > > > > regardless of how verbose it would be?
> > > > > 
> > > > > because there is a wide diversity of plugins (more than 5,000 in
> > > 
> > > Central
> > > 
> > > > > Repository), then nobody can define everything
> > > > > 
> > > > > We need something extensible
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit :
> > > > > > As far as I understand, depending on maven version, the list of
> > > 
> > > default
> > > 
> > > > > > plugin versions is different. One way I go around this is by using
> > > 
> > > maven
> > > 
> > > > > > wrapper, which also downloads the required maven version by the
> > > 
> > > project.
> > > 
> > > > > > The other way to go around this is to define all the plugin
> > 
> > versions
> > 
> > > > > > yourself. But my question is why not add a feature where maven
> > 
> > would
> > 
> > > > > > produce a pom that contains the default plugins, repositories, and
> > > 
> > > etc.
> > > 
> > > > > > regardless of how verbose it would be?
> > > > > > 
> > > > > > On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY 
> > > 
> > > wrote:
> > > > &g

Re: Maven superpom, JUnit 5 and Spring

[Hervé BOUTEMY]

if you're talking about the little subset that we use for our default 
packaging bindings [1], as you can see from the page, there is already a 
version fixed by the bindings

but:
1. that ties you to a precise Maven version, which is something we want to 
avoid
2. it does not work for the many other plugins

that's why any discussion is about making something flexible, and not focusing 
only on the few plugins used by default packagings

regards,

Hervé

[1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html

Le dimanche 7 mars 2021, 15:43:45 CET Mantas Gridinas a écrit :
> Maven does not provide all of those 5 thousand plugins by default, does it?
> 
> On Sun, Mar 7, 2021 at 11:39 AM Hervé BOUTEMY  wrote:
> > > But my question is why not add a feature where maven would
> > > produce a pom that contains the default plugins, repositories, and etc.
> > > regardless of how verbose it would be?
> > 
> > because there is a wide diversity of plugins (more than 5,000 in Central
> > Repository), then nobody can define everything
> > 
> > We need something extensible
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit :
> > > As far as I understand, depending on maven version, the list of default
> > > plugin versions is different. One way I go around this is by using maven
> > > wrapper, which also downloads the required maven version by the project.
> > > 
> > > The other way to go around this is to define all the plugin versions
> > > yourself. But my question is why not add a feature where maven would
> > > produce a pom that contains the default plugins, repositories, and etc.
> > > regardless of how verbose it would be?
> > > 
> > > On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY  wrote:
> > > > sorry, I don't understand: can you explain a little more what you mean
> > > > by
> > > > "produce the implied pom" and "some issues of irreproducability"?
> > > > 
> > > > Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit :
> > > > > Why not provide an ability to produce the implied pom explicitly in
> > > > > current project as well? This way you would get around some issues
> > > > > of
> > > > > irreproducability.
> > > > > 
> > > > > On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY 
> > > > 
> > > > wrote:
> > > > > > every existing plugin version can't be defined by Maven itself,
> > > > > > given
> > > > > > diversity of plugins
> > > > > > then we need something extensible
> > > > > > 
> > > > > > there is https://issues.apache.org/jira/browse/MNG-5588 ,
> > > > > > proposing to
> > > > > > mimic dependencyManagement import to get an equivalent
> > > > > > pluginManagement
> > > > > > import
> > > > > > 
> > > > > > I love this idea, which is currently blocked by one stupid
> > > > > > concrete
> > > > 
> > > > issue:
> > > > > > there is no "scope" field in plugin definition
> > > > > > 
> > > > > > looking at model:
> > > > > > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_pl
> > > > > > ugin
> > > > > > 
> > > > > > perhaps we could abuse plugin's "inherited" field, the same way we
> > > > 
> > > > abused
> > > > 
> > > > > > "scope" field of dependencies...
> > > > > > 
> > > > > > Any taker to work with me on trying to code that?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Hervé
> > > > > > 
> > > > > > Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit :
> > > > > > > I agree with the recommendations made by Anthony, and that best
> > > > 
> > > > practice
> > > > 
> > > > > > > is
> > > > > > > to specify all versions explicitly.
> > > > > > > 
> > > > > > > However, I am also empathetic to the concerns raised by Tilman.
> > > > > > > When
> > > > > > > people
> > > > > > > compare Maven to other build tools

Re: Maven superpom, JUnit 5 and Spring

[Hervé BOUTEMY]

> But my question is why not add a feature where maven would
> produce a pom that contains the default plugins, repositories, and etc.
> regardless of how verbose it would be?
because there is a wide diversity of plugins (more than 5,000 in Central 
Repository), then nobody can define everything

We need something extensible

Regards,

Hervé

Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit :
> As far as I understand, depending on maven version, the list of default
> plugin versions is different. One way I go around this is by using maven
> wrapper, which also downloads the required maven version by the project.
> 
> The other way to go around this is to define all the plugin versions
> yourself. But my question is why not add a feature where maven would
> produce a pom that contains the default plugins, repositories, and etc.
> regardless of how verbose it would be?
> 
> On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY  wrote:
> > sorry, I don't understand: can you explain a little more what you mean by
> > "produce the implied pom" and "some issues of irreproducability"?
> > 
> > Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit :
> > > Why not provide an ability to produce the implied pom explicitly in
> > > current project as well? This way you would get around some issues of
> > > irreproducability.
> > > 
> > > On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY 
> > 
> > wrote:
> > > > every existing plugin version can't be defined by Maven itself, given
> > > > diversity of plugins
> > > > then we need something extensible
> > > > 
> > > > there is https://issues.apache.org/jira/browse/MNG-5588 , proposing to
> > > > mimic dependencyManagement import to get an equivalent
> > > > pluginManagement
> > > > import
> > > > 
> > > > I love this idea, which is currently blocked by one stupid concrete
> > 
> > issue:
> > > > there is no "scope" field in plugin definition
> > > > 
> > > > looking at model:
> > > > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_plugin
> > > > 
> > > > perhaps we could abuse plugin's "inherited" field, the same way we
> > 
> > abused
> > 
> > > > "scope" field of dependencies...
> > > > 
> > > > Any taker to work with me on trying to code that?
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit :
> > > > > I agree with the recommendations made by Anthony, and that best
> > 
> > practice
> > 
> > > > > is
> > > > > to specify all versions explicitly.
> > > > > 
> > > > > However, I am also empathetic to the concerns raised by Tilman. When
> > > > > people
> > > > > compare Maven to other build tools and complain about the verbosity
> > 
> > of
> > 
> > > > > POM
> > > > > files, a lot of that verbosity comes from having to specify versions
> > 
> > for
> > 
> > > > > plugins, including plugins that are part of the default lifecycle.
> > > > > 
> > > > > If we agree that Maven follows a convention over configuration
> > 
> > design,
> > 
> > > > > perhaps the Super POM should be updated to some more sensible
> > 
> > defaults.
> > 
> > > > > While it may not be as reproducible to leave them unspecified, it
> > 
> > would
> > 
> > > > > reduce the surprise to beginners when now very outdated plugin
> > 
> > versions
> > 
> > > > > are
> > > > > used by default.
> > > > > 
> > > > > Greg
> > > > > 
> > > > > On Mon, Feb 22, 2021 at 3:44 PM Anthony Whitford <
> > 
> > anth...@whitford.com>
> > 
> > > > > wrote:
> > > > > > I recommend reading the “Important Note” found here:
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in
> > 
> > > > > > trod
> > > > > > uction <
> > 
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in
> > 
> > > > > > trod
> > > > > > uction>
> > > > > > 
> > > > > > > Important Note: Alwa

Re: Maven superpom, JUnit 5 and Spring

[Hervé BOUTEMY]

sorry, I don't understand: can you explain a little more what you mean by 
"produce the implied pom" and "some issues of irreproducability"?

Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit :
> Why not provide an ability to produce the implied pom explicitly in
> current project as well? This way you would get around some issues of
> irreproducability.
> 
> On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY  wrote:
> > every existing plugin version can't be defined by Maven itself, given
> > diversity of plugins
> > then we need something extensible
> > 
> > there is https://issues.apache.org/jira/browse/MNG-5588 , proposing to
> > mimic dependencyManagement import to get an equivalent pluginManagement
> > import
> > 
> > I love this idea, which is currently blocked by one stupid concrete issue:
> > there is no "scope" field in plugin definition
> > 
> > looking at model:
> > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_plugin
> > 
> > perhaps we could abuse plugin's "inherited" field, the same way we abused
> > "scope" field of dependencies...
> > 
> > Any taker to work with me on trying to code that?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit :
> > > I agree with the recommendations made by Anthony, and that best practice
> > > is
> > > to specify all versions explicitly.
> > > 
> > > However, I am also empathetic to the concerns raised by Tilman. When
> > > people
> > > compare Maven to other build tools and complain about the verbosity of
> > > POM
> > > files, a lot of that verbosity comes from having to specify versions for
> > > plugins, including plugins that are part of the default lifecycle.
> > > 
> > > If we agree that Maven follows a convention over configuration design,
> > > perhaps the Super POM should be updated to some more sensible defaults.
> > > While it may not be as reproducible to leave them unspecified, it would
> > > reduce the surprise to beginners when now very outdated plugin versions
> > > are
> > > used by default.
> > > 
> > > Greg
> > > 
> > > On Mon, Feb 22, 2021 at 3:44 PM Anthony Whitford 
> > > 
> > > wrote:
> > > > I recommend reading the “Important Note” found here:
> > > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in
> > > > trod
> > > > uction <
> > > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in
> > > > trod
> > > > uction>
> > > > 
> > > > > Important Note: Always define each version of the plugins used by
> > > > > the
> > > > 
> > > > build to guarantee the build reproducibility. A good practice is to
> > > > specify
> > > > them in the  elements for each build
> > > > plugins. (Generally, you will define a  element in
> > > > a
> > > > parent POM.) For reporting plugins, specify each version in the
> > > >  elements (and surely in the
> > > >  elements too).
> > > > 
> > > > 
> > > > In other words, do not rely on the implied Super Parent Pom for
> > > > defining
> > > > plugin versions because it will not guarantee build reproducibility.
> > > > Instead, your pom hierarchy should explicitly declare the plugin
> > > > versions
> > > > to use.  (Maintaining a corporate pom that may be used across projects
> > > > might be a wise approach.)
> > > > 
> > > > > On Feb 22, 2021, at 11:11 AM, Tilman Hausherr
> > > > > 
> > > > 
> > > > wrote:
> > > > > Hello,
> > > > > 
> > > > > I'm using maven 3.6.3 and the maven-surefire-plugin version used in
> > > > > a
> > > > 
> > > > build is 2.12.4 when the version is not specified, the "effective"
> > > > version
> > > > is 2.10. For junit 5 one needs 2.22.2, see
> > > > 
> > > > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-> 
> > > > > > > mave
> > > > n
> > > > 
> > > > > this is a pitfall for JUnit 5 users:
> > > > > https://stackoverflow.com/a/66313961/535646
> > > > > who don't read the manual. Should I create a JIRA issue that the
> > > > > super
> > > > 
> > > > pom should be updated? Or is another plugin to "blame" for the default
> > > > version?
> > > > 
> > > > > Tilman
> > > > > 
> > > > > 
> > > > > 
> > > > > -
> > > > > 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





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven superpom, JUnit 5 and Spring

[Hervé BOUTEMY]

every existing plugin version can't be defined by Maven itself, given diversity 
of plugins
then we need something extensible

there is https://issues.apache.org/jira/browse/MNG-5588 , proposing to mimic 
dependencyManagement import to get an equivalent pluginManagement import

I love this idea, which is currently blocked by one stupid concrete issue: 
there is no "scope" field in plugin definition

looking at model:
https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_plugin

perhaps we could abuse plugin's "inherited" field, the same way we abused 
"scope" field of dependencies...

Any taker to work with me on trying to code that?

Regards,

Hervé

Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit :
> I agree with the recommendations made by Anthony, and that best practice is
> to specify all versions explicitly.
> 
> However, I am also empathetic to the concerns raised by Tilman. When people
> compare Maven to other build tools and complain about the verbosity of POM
> files, a lot of that verbosity comes from having to specify versions for
> plugins, including plugins that are part of the default lifecycle.
> 
> If we agree that Maven follows a convention over configuration design,
> perhaps the Super POM should be updated to some more sensible defaults.
> While it may not be as reproducible to leave them unspecified, it would
> reduce the surprise to beginners when now very outdated plugin versions are
> used by default.
> 
> Greg
> 
> On Mon, Feb 22, 2021 at 3:44 PM Anthony Whitford 
> 
> wrote:
> > I recommend reading the “Important Note” found here:
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > uction <
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > uction> 
> > > Important Note: Always define each version of the plugins used by the
> > 
> > build to guarantee the build reproducibility. A good practice is to
> > specify
> > them in the  elements for each build
> > plugins. (Generally, you will define a  element in a
> > parent POM.) For reporting plugins, specify each version in the
> >  elements (and surely in the
> >  elements too).
> > 
> > 
> > In other words, do not rely on the implied Super Parent Pom for defining
> > plugin versions because it will not guarantee build reproducibility.
> > Instead, your pom hierarchy should explicitly declare the plugin versions
> > to use.  (Maintaining a corporate pom that may be used across projects
> > might be a wise approach.)
> > 
> > > On Feb 22, 2021, at 11:11 AM, Tilman Hausherr 
> > 
> > wrote:
> > > Hello,
> > > 
> > > I'm using maven 3.6.3 and the maven-surefire-plugin version used in a
> > 
> > build is 2.12.4 when the version is not specified, the "effective" version
> > is 2.10. For junit 5 one needs 2.22.2, see
> > 
> > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-mave
> > n
> > 
> > > this is a pitfall for JUnit 5 users:
> > > https://stackoverflow.com/a/66313961/535646
> > > who don't read the manual. Should I create a JIRA issue that the super
> > 
> > pom should be updated? Or is another plugin to "blame" for the default
> > version?
> > 
> > > Tilman
> > > 
> > > 
> > > -
> > > 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: Removing the text "Generated by maven-plugin-tools 3.5 on 2021-02-11"

[Hervé BOUTEMY]

not exactly: this already has been done for release 3.5.1
https://issues.apache.org/jira/browse/MPLUGIN-326

so you just need to upgrade a little bit :)

Regards,

Hervé

Le samedi 6 mars 2021, 22:22:36 CET Lutz Horn a écrit :
> > After creating a maven plugin I am seeing the automated text
> > "Generated by maven-plugin-tools 3.5 on 2021-02-11" on my plugin.xml file.
> > 
> > I want this text message to be removed . How to achieve this?
> 
> This line is generated by the class PluginDescriptorGenerator here:
> 
> https://github.com/apache/maven-plugin-tools/blob/9107632fe99a2d40794d97973b
> 2421df1a520e82/maven-plugin-tools-generators/src/main/java/org/apache/maven/
> tools/plugin/generator/PluginDescriptorGenerator.java#L132
> 
> As you can see from the code, this line is always generated as a XML
> comment together with XML elements like 'name' and 'description'. If you
> want to change the behaviour of this class, you will have to patch it.
> 
> Lutz
> 
> -
> 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: properties in maven-remote-resources-plugin

[Hervé BOUTEMY]

please try to write:

  
1.12
  

in you pom.xml = it defines a custom property with the value you want

this will permit 
"dbs:commondb:${dep.dbs.commondb}" to get the 
value replaced

Notice that images are removed, then we don't understand what you're trying to 
show

Regards,

Hervé

Le samedi 27 février 2021, 08:03:33 CET Delany a écrit :
> I didn't want to give you all the context, because that complicates the
> problem which I carefully worded in the initial email:
> 
> "I don't want to hardcode the version number of the remote project into
> this plugin config, so I've used a property made available in a parent pom."
> 
> The fact that I don't use that version number property in the project that
> bundles the remote resources is immaterial. The problem is that the process
> goal in this receiving project will recognize one property
> "project.version" and not another "dep.dbs.commondb". It does that because
> project.version is one of the default properties the plugin passes through
> to its templating logic, I quote
> 
> "Additional properties to be passed to Velocity. Several properties are
> automatically added:"
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.
> html#properties
> 
> So has anyone ever successfully passed through a non-default property? Or
> is this dead code no one ever uses.
> The example given here
>  ring-resources.html> demonstrates using the project.version property. But
> you don't need to use the properties tag for that. There are no examples
> showing the use of the properties tag of this goal.
> 
> [image: image.png]
> 
> The link at the bottom is to some generic javadoc about properties, and it
> happens to be dead.
> 
> Thanks,
> 
> On Sat, 27 Feb 2021 at 05:47, Anthony Whitford  wrote:
> > I’m honestly unclear on your precise scenario.
> > 1.  If you are expecting a dependency to have a pom with a variable in it,
> > that then you would specify before using it, then Maven doesn’t work that
> > way.  (And if you think about it, it creates a chicken-egg problem.)
> > 2.  If you are expecting to use a pom property from a dependency, then you
> > can’t do that either.  (And if you think about it, that could be dangerous
> > because children properties could collide or interfere with your own.)
> > 
> > Note that you can declare a dependency/plugin and override a dependency —
> > sometimes that is useful.
> > 
> > I highly recommend  `mvn help:effective-pom` to see exactly what a
> > project’s pom results look like; it can be insightful.
> > 
> > You can also use  `mvn help:evaluate` to see the value of expressions.
> > 
> > This is also a good reference:
> > https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > roperties.html <
> > https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > roperties.html
> > 
> > 
> > Hope this helps,
> > 
> > Anthony
> > 
> > > On Feb 23, 2021, at 11:32 PM, Delany  wrote:
> > > 
> > > Thanks I know how to use properties, but this plugin doesn't, it seems.
> > 
> > It has some special way of importing them:
> > 
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > o.html <
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > o.html> 
> > > It can do this
> > 
> > org.test:shared-resources:${project.version} > le>> 
> > > But this is the version of this project, not the resource bundle
> > 
> > org.test:shared-resources. Why would I ever do that? The plugin is
> > assuming
> > that all project modules in the reactor have the same version.
> > 
> > > I need it to do this
> > 
> > org.test:shared-resources:${shared-resources.version} > ourceBundle>> 
> > > It looks like if I make commondb a dependency, I can use the projects
> > 
> > property to access the version number. How do I do that?
> > 
> > > Thanks,
> > > Delany
> > > 
> > > 
> > > On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  > 
> > > wrote:
> > > The  tag is documented here:
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties> <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties> 
> > > > On Feb 23, 2021, at 3:34 AM, Delany  > 
> > > wrote:
> > > > I don't want to hardcode the version number of the remote project into
> > 
> > this
> > 
> > > > plugin config, so I've used a property made available in a parent pom.
> > > > But it's not being resolved. What am I doing wrong?
> > > > 
> > > >  
> > > >  
> > > >maven-remote-resources-plugin
> > > >
> > > >
> > > >  
> > > >  
> > > >  

[ANN] Apache Maven Artifact Plugin 3.0.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Artifact 
Plugin, version 3.0.0

This plugin manage artifacts tasks, currently check Reproducible Builds.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.0.0



Release Notes - Apache Maven Artifact Plugin - Version 3.0.0

Improvement
* [MARTIFACT-3] Allow to check javadoc

New Feature
* [MARTIFACT-12] configure ignored types & classifiers
* [MARTIFACT-11] multi-module: copy also aggregate buildinfo.compare to root 
target
* [MARTIFACT-8] multi-module: copy aggregate buildinfo to root target
* [MARTIFACT-7] record toolchain JVM usage in buildinfo
* [MARTIFACT-4] add an option to buildinfo goal to take javadoc into account 
(false by default)

Task
* [MARTIFACT-2] First version release


Enjoy,

-The Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Archetype Plugin 3.0.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Artifact 
Plugin, version 3.0.0

This plugin manage artifacts tasks, currently check Reproducible Builds.

https://maven.apache.org/plugins/maven-artifact-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-artifact-plugin
  3.0.0



Release Notes - Apache Maven Artifact Plugin - Version 3.0.0

Improvement
* [MARTIFACT-3] Allow to check javadoc

New Feature
* [MARTIFACT-12] configure ignored types & classifiers
* [MARTIFACT-11] multi-module: copy also aggregate buildinfo.compare to root 
target
* [MARTIFACT-8] multi-module: copy aggregate buildinfo to root target
* [MARTIFACT-7] record toolchain JVM usage in buildinfo
* [MARTIFACT-4] add an option to buildinfo goal to take javadoc into account 
(false by default)

Task
* [MARTIFACT-2] First version release


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Hervé BOUTEMY]

I wrote a doc for deploying to local staging directory [1] in Maven Deploy 
Plugin documentation (not yet released)

perhaps this can be of use

Regards,

Hervé

[1] 
https://maven.apache.org/plugins-archives/maven-deploy-plugin-LATEST/examples/deploy-network-issues.html

Le vendredi 5 février 2021, 18:52:09 CET Andres Almiray a écrit :
> @Tamás: Right, should had explained the use case. I want to deploy all
> artifacts to a local directory so that I can inspect everything which will
> be deployed given certain conditions.
> I managed to do that by forcing a stable, absolute directory as shown at
> 
> https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa57992921
> 1aac20bef3f5e00
> 
> I'd prefer if the target directory be ${rootProject.build.directory} if
> there were such things as {$rootProject}, which is why I'm asking for a way
> to find out that value.
> As you may appreciate in that commit the value is used as part of
>  in a profile.
> 
> @Lasse: I thought using that plugin would work but not in my case as the
> computed property is not available during model interpolation which is my
> case for setting the correct value in 
> 
> Cheers,
> Andres
> 
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
> 
> 
> On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist 
> wrote:
> > Using directory-maven-plugin and highest-basedir goal from it has worked
> > just fine for me.
> > https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
> > 
> > pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> > 
> > kirjoitti:
> > > Howdy,
> > > Grab somehow (you did not state from where if "outside of plugins")
> > > MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> > > what you want, as one may use -f param for example...
> > > 
> > > So, I'd shoot back: WHY do you need the root of a multi module build and
> > > FROM WHAT you need it? Extension?
> > > Are you sure you can expect maven is invoked from root? Could it be
> > 
> > simpler
> > 
> > > just to pass in as some parameter maybe, instead of doing all sorts of
> > > hoops and loops?
> > > 
> > > T
> > > 
> > > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> > 
> > wrote:
> > > > Hello everyone,
> > > > 
> > > > Is there a way to reliably resolve the value of the root directory for
> > 
> > a
> > 
> > > > given multi-project build?
> > > > Unfortunately ${session.executionRootDirectory} does not seem to work
> > 
> > for
> > 
> > > > all cases, it might work when used inside a plugin's 
> > > > section but does not when used outside of plugins
> > > > 
> > > > TIA
> > > > 
> > > > Cheers,
> > > > Andres
> > > > 
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > http://andresalmiray.com
> > > > http://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> > > > binary,
> > > 
> > > and
> > > 
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Computing and publishing checksums

[Hervé BOUTEMY]

Le mardi 16 février 2021, 00:34:45 CET Andres Almiray a écrit :
> Hi Hervé,
> 
> That's right, I can see MD5 and SHA1 checksums for the
> sdkman-maven-plugin[1] which uses the deploy, release, and nexus-staging
> plugins for publication.
> However I didn't see an option for SHA256 or SHA512 which is why I asked. I
> also found the net.nicoulaj.maven.plugins:checksum-maven-plugin plugin and
> wondered if that would be the one to use going forward, thanks for
> confirming.
I did not confirm *if it's to deploy to your repository*, but only if it's for 
other purposes.

> 
> Given that MD5 and SHA1 are already published during deployment I'd prefer
> if SHA256 and SHA512 were also published at the same location, I suppose I
> can configure checksum-maven-plugin for that to happen.
I suppose checksum-maven-plugin won't properly work, because when it will 
attach .sha512, deploy will calculate .sha512.sha1 and .sha512.md5: you should 
check for such noise

I don't know if someone has a plan to add sha256/sha512 to deploy (Robert 
Scholte?).
Personally, I think this feature just gives wrong sense of safety:
1. if checksum is for network control, sha1 and even md5 are sufficient,
2. if it's against malicious actors, malicious actor will tamper the checksum 
when tampering the binary.
If you want protection against malicious actors, pgp signatures verification is 
the way to go.

> Regarding reproducible builds, while it may not be required to publish
> checksums you do need to check them against a previous value. Of course you
> can check the value locally if you build twice, but you'd also want to
> check the value against an "official" valkue, or at least a previously
> published value.
yes: maven-artifact-plugin downloads reference "official" binaries and 
calculates checksums, no need to download pre-calculated checksums (that you 
eventually should not trust).
It's what Reproducible Central does successfully at large scale, without any 
.buildinfo being available on Central repository.

REX part 2: the only really useful info in .buildinfo to publish to Central 
repository may be the effective environment: which OS, which JVM, which build 
tool version? = something currently Maven Artifact Plugins guesses from jar 
content: that's why I wrote "eventually", because these guesses are currently 
enough in real world...
Everything else can be computed later, when trying to compare local build 
output against reference binaries.

> I'm keen in discussing reproducible builds as I
> implemented a similar plugin for Gradle (which provides similar behavior,
> yet no aggregates so far).
I'm very interested to add Gradle support to Reproducible Central: do you know 
any artifact in Central that is expected to be reproducible?

We can first check by hand (basically rebuilding by hand and checking by hand 
output binaries), then automating the reproducible build check = what 
Reproducible Central is, with currently Maven and SBT support, but I would 
love to add other build tools

Regards,

Hervé

> 
> Cheers,
> Andres
> 
> [1] https://repo1.maven.org/maven2/io/sdkman/sdkman-maven-plugin/2.0.0/
> 
> 
> 
> On Mon, Feb 15, 2021 at 11:51 PM Hervé BOUTEMY 
> 
> wrote:
> > Hi Andres,
> > 
> > Le lundi 15 février 2021, 21:52:03 CET Andres Almiray a écrit :
> > > Hello there,
> > > 
> > > What's the recommended way to compute and publish checksums (several
> > > algorithms such as MD5, SHA256, SHA512) for all artifacts (POMs y binary
> > > JARs at the very least, sources & javadocs may be excluded).
> > 
> > the question is: where do you want to publish, with what process?
> > 
> > If it's to your remote repository, maven-deploy-plugin does the job
> > 
> > If it's local to your build (then you do whatever you want with the files
> > in
> > your own publication process), we use net.nicoulaj.maven.plugins:checksum-
> > maven-plugin at Apache Software Foundation parent build level to compute
> > sha512 checksum of source release archives, that are later published to
> > Apache
> > Software Distribution area.
> > see https://maven.apache.org/pom/asf/#The_apache-release_Profile and
> > corresponding pom.xml
> > 
> > > I'm aware that reproducible builds[1] requires publishing checksums in a
> > > .buildinfo file and that the Maven artifacts plugin 3.0.0 will be
> > 
> > released
> > 
> > > soon (-ish).
> > 
> > I would not say that " reproducible builds[1] requires publishing
> > checksums in
> > a .buildinfo file": Reproducible Builds require that if you build twice
> > and
> > compute checksums, you'll get the same value.
> > 
> > You don't need

Re: Computing and publishing checksums

[Hervé BOUTEMY]

Hi Andres,

Le lundi 15 février 2021, 21:52:03 CET Andres Almiray a écrit :
> Hello there,
> 
> What's the recommended way to compute and publish checksums (several
> algorithms such as MD5, SHA256, SHA512) for all artifacts (POMs y binary
> JARs at the very least, sources & javadocs may be excluded).
the question is: where do you want to publish, with what process?

If it's to your remote repository, maven-deploy-plugin does the job

If it's local to your build (then you do whatever you want with the files in 
your own publication process), we use net.nicoulaj.maven.plugins:checksum-
maven-plugin at Apache Software Foundation parent build level to compute 
sha512 checksum of source release archives, that are later published to Apache 
Software Distribution area.
see https://maven.apache.org/pom/asf/#The_apache-release_Profile and 
corresponding pom.xml

> 
> I'm aware that reproducible builds[1] requires publishing checksums in a
> .buildinfo file and that the Maven artifacts plugin 3.0.0 will be released
> soon (-ish).
I would not say that " reproducible builds[1] requires publishing checksums in 
a .buildinfo file": Reproducible Builds require that if you build twice and 
compute checksums, you'll get the same value.

You don't need to publish your checksums: anybody can compute checksums at any 
time, that's what Maven Artifact Plugin does on the fly both for current build 
result and from remote reference build binaries.
That's what is done in Reproducible Central, for example:
https://github.com/jvm-repo-rebuild/reproducible-central

And to be clear, I'm not sure that publishing .buildinfo to Central repository 
is a good idea, particularly when the spec I wrote [1] is SNAPSHOT, 
implemented only by few tools, never had any real feedback, and that I 
implemented in Maven Artifact Plugin something that is finally different from 
the theory I wrote 1 year before in the spec.

First part of REX: only SBT implemented .buildinfo, and published the output 
to Central for com.scalapenos:stamina releases (visible in Reproducible 
Central) and a few other. And it showed one of the first issues: on a build 
that produces many gavs (multi-modules in Maven, multi-scala versions in SBT), 
is it better to produce 1 unique .buildinfo for the whole multi-module build 
(like I did in Maven Artifact Plugin) or to produce 1 .buildinfo file per gav 
(like done in SBT case)?

I know that I need to take time to write some REX on the issues I encountered 
when implementing the spec.
If you're interested, I will probably take time to write this REX: I'm tired 
on writing many documentations that nobody gives feedback on, after having 
really used.

Regards,

Hervé

> 
> Cheers,
> Andres
> 
> [1] https://reproducible-builds.org/docs/jvm/





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven EAR Plugin 3.2.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven EAR 
Plugin, version 3.2.0

This plugin generates a J2EE Enterprise Archive (EAR) file.

https://maven.apache.org/plugins/maven-ear-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-ear-plugin
  3.2.0



Release Notes - Apache Maven EAR Plugin - Version 3.2.0

Bug
* [MEAR-294] JAR with provided scope should be removed from Class-Path entry of 
EAR module MANIFEST.mf
* [MEAR-292] skipClassPathModification option should prevent adding Class-Path 
entry into MANIFEST.mf
* [MEAR-289] skinnyWars issue with finalName for Jar module
* [MEAR-288] SNAPSHOT dependency JAR having timestamp name in WAR is not 
removed from WAR when skinnyWars option is turned on
* [MEAR-287] Failed to create target directory when run without clean
* [MEAR-286] filtered resources not copied if run-its profile not activated
* [MEAR-272] SNAPSHOT dependencies are copied with timestamp
* [MEAR-267] assembly.xml contains incorrect references to modules

Improvement
* [MEAR-216] Unable to include dependencies of type test-jar

New Feature
* [MEAR-166] 'skinnyWar' doesn't work well with dependencies of type 'ejb'
* [MEAR-153] Skinny Modules -- not just WARs

Task
* [MEAR-296] Upgrade to maven-filtering 3.2.0
* [MEAR-295] Require Maven 3.1.1


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven SCM Publish Plugin 3.1.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven SCM 
Publish Plugin, version 3.1.0

The maven-scm-publish-plugin is a utility plugin to allow publishing Maven 
website to any supported SCM.

https://maven.apache.org/plugins/maven-scm-publish-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-scm-publish-plugin
  3.1.0



Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0

Bug
* [MSCMPUB-42] Can't publish to file:// URL containing an @
* [MSCMPUB-13] automaticRemotePathCreation does not create parent directories

Improvement
* [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code around 
File.createTempFile(...)
* [MSCMPUB-45] make build Reproducible

New Feature
* [MSCMPUB-41] Publish in repository sub-folder
* [MSCMPUB-40] Ability to skip this plugin execution via a config property

Task
* [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal
* [MSCMPUB-39] Upgrade maven-plugins parent to 33.
* [MSCMPUB-37] Upgrade to SCM 1.10.0


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges: bug or feature

[Hervé BOUTEMY]

as Tomo said:
1. version ranges make dependencies selection unstable: is it really 
necessary? (I personnally never use because of the build instability it adds, 
given I'm trying to go even beyond stable build: I'm working hard on 
Reproducible Builds [1]. Then my experience on detailed behaviour of such 
configuration is limited, sorry...)

2. this range includes versions such as "7.0.0-alpha" and "7.0.0-rc": from my 
experience on working on code for version comparison and version range, I 
imagine that when people write [..., 7.0.0-SNAPSHOT), what they really intent 
is to avoid even 7.0.0-alpha, beta, rc, then they should probably better write 
[..., 7.0.0-alpha-alpha)
I know this is not fully intuitive.
I remember some old discussions on defining some more precise semantics for 
version ranges, both for effective vs declared limits and SNAPSHOT inclusion of 
not, but IIRC this never went to an implementation
My thoughts at that time is that Maven currently implements version ranges as 
pure mathematical range, where what people expect is not really math but 
something that will match an intent.

Changes on version range use cases and semantic evolution are hard, we need to 
define what are the different intents, then how to express them, then 
implement, 
and avoid that Central Repository contains unusable libraries when we update 
version range semantics (= what we are currently tackling with Maven 3.7 work 
in progress): I know there are MNG issues and perhaps MRESOLVER ones, perhaps 
Wiki. Summarising links would already be a hard job...

Hope this helps

Regards,

Hervé

[1] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=abrarovm

Le mardi 10 novembre 2020, 16:34:21 CET Maxim Solodovnik a écrit :
> Thanks for the quick answer Tomo,
> 
> According to out build logs (available for ex. here [1])
> `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions in
> all snapshot repositories available
> 
> so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked ...
> Is this expected
> 
> https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFu
> ll
> 
> 
> 
> On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki 
> 
> wrote:
> > I avoid using version ranges because it introduces unexpected results in
> > the dependency graphs.
> > 
> > > [6.7.0,7.0.0-SNAPSHOT)
> > 
> > I felt the intention of the range is the highest version before
> > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > As per [1], this range includes versions such as "7.0.0-alpha" and
> > "7.0.0-rc".
> > 
> > [1]:
> > 
> > https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven
> > /artifact/versioning/ComparableVersion.html ,
> > 
> > 
> > 
> > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik 
> > 
> > wrote:
> > > Hello Maven experts,
> > > 
> > > one sub-dependencies of our project has following
> > > 
> > >   [6.7.0,7.0.0-SNAPSHOT)
> > > 
> > > [1]
> > > 
> > > as a result metadata for all available SNAPSHOT version is being checked
> > 
> > in
> > 
> > > all SNAPSHOT repositories
> > > this takes time
> > > (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > > 
> > > this is reproducible using both local build and build at
> > > ci-builds.apache.org
> > > 
> > > Is this expected behavior?
> > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > library?
> > > 
> > > 
> > > 
> > > [1]
> > 
> > https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api
> > -elements-6.15.0.pom> 
> > > --
> > > Best regards,
> > > Maxim
> > 
> > --
> > Regards,
> > Tomo





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Maven EAR Plugin 3.1.2 Released

[Hervé BOUTEMY]

for those interested, issue created and being worked on:
https://issues.apache.org/jira/browse/MEAR-287

I suppose this is a blocker that will require a new release soon, isn't it?

please help us by testing as early as possible, to find such issues ASAP and 
ideally before the release

Regards,

Hervé

Le jeudi 1 octobre 2020, 09:16:12 CEST Martin Höller a écrit :
> Hi!
> 
> On 01. Okt. 2020 Hervé Boutemy wrote:
> > The Maven team is pleased to announce the release of the Apache Maven EAR
> > Plugin, version 3.1.0
> With maven-ear-plugin 3.1.0 I get this exception on a project that built
> fine with 3.0.2:
> 
> $ mvn -X install
> [...]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on
> project demo-ear: Failed to create directory
> /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new-
> 3.0-SNAPSHOT.war -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on
> project demo-ear: Failed to create directory
> /home/martin/idea/demo/demo-ear/target/temp/my.domaon.demo-demo-webapp-new-
> 3.0-SNAPSHOT.war at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81) at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu
> ilder.build (SingleThreadedBuilder.java:56) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute
> (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute
> (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62) at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke
> (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225) at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406) at
> org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to create
> directory
> /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new-
> 3.0-SNAPSHOT.war at
> org.apache.maven.plugins.ear.EarMojo.changeManifestClasspath
> (EarMojo.java:763) at org.apache.maven.plugins.ear.EarMojo.copyModules
> (EarMojo.java:466) at org.apache.maven.plugins.ear.EarMojo.execute
> (EarMojo.java:336) at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81) at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu
> ilder.build (SingleThreadedBuilder.java:56) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute
> (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute
> (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native M

[ANN] Apache Maven EAR Plugin 3.1.2 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven EAR 
Plugin, version 3.1.0

This plugin generates a J2EE Enterprise Archive (EAR) file.

https://maven.apache.org/plugins/maven-ear-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-ear-plugin
  3.1.0



Release Notes - Apache Maven EAR Plugin - Version 3.1.0

Bug
* [MEAR-285] EarMojo fails to handle assorted IO Errors
* [MEAR-283] Not reproducible builds when skinnyWars option turned on
* [MEAR-278] Ear plugin includes the same artifact twice if used without clean

Improvement
* [MEAR-279] make build Reproducible
* [MEAR-194] Output during creation of Ear is not correct

New Feature
* [MEAR-280] Reproducible Builds: make entries in output ear files reproducible 
(order + timestamp)

Task
* [MEAR-284] Tests fail at HEAD on Linux
* [MEAR-276] Upgrade maven-archiver to 3.4.0


Thank you to all contributors who helped to make this release.

Enjoy,

-The Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Return a custom error message from the repository

[Hervé BOUTEMY]

Hello,

Maven uses HTTP ReasonPhrase: see MNG-6584 [1]

Notice that ReasonPhrase support has been removed in HTTP/2, then we should 
define a new strategy: waiting for contributors from different horizons to be 
interested in working on that to define (and this time properly document) a new 
strategy that will have to be implemented by webservers serving content in 
Maven2 repository format

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MNG-6584

Le mercredi 9 septembre 2020, 00:13:21 CEST Steve Abrams a écrit :
> Hello,
> 
> I'm working on the GitLab maven repository and was trying to find out if
> there is a way to attach a custom error message (or any custom message in
> general) to the response so when a command like "mvn deploy" fails due to
> an error in the remote repository, the user can see some sort of helpful
> message. (GitLab issue for context:
> https://gitlab.com/gitlab-org/gitlab/-/issues/241788)
> 
> Thank you!
> 
> *Steve Abrams* | Backend Engineer - Package
> sabr...@gitlab.com  | @s
> abrams
> Time zone: MT





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Archetype 3.2.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Archetype, version 3.2.0.

The Archetype Plugin allows the user to create a Maven project from an existing 
template called an archetype.
It also allows the user to create an archetype from an existing project.

https://maven.apache.org/archetype/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-archetype-plugin
  3.2.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/archetype/download.cgi

Release Notes - Maven Archetype - Version 3.2.0

** Bug
* [ARCHETYPE-585] - Missing null check causes NullPointerException

** New Feature
* [ARCHETYPE-590] - support Reproducible Builds for archetype:jar

** Improvement
* [ARCHETYPE-583] - Skip parent non-archetype project when updating local 
catalog
* [ARCHETYPE-586] - make build Reproducible

** Dependency upgrade
* [ARCHETYPE-594] - Update easymock
* [ARCHETYPE-596] - Update xmlunit


Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven WAR Plugin 3.3.1 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven WAR 
Plugin, version 3.3.1

This plugin builds a Web Application Archive (WAR) file from the project output 
and its dependencies.

https://maven.apache.org/plugins/maven-war-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-war-plugin
  3.3.1



Release Notes - Apache Maven WAR Plugin - Version 3.3.1

Bug
* [MWAR-436] Jar file created by archiveClasses option is not reproducible
* [MWAR-435] Maven WAR Plugin 3.3.0 with minify-maven-plugin does not work 
correctly anymore
* [MWAR-434] archiveClasses Jar file is not created in WEB-INF/lib
* [MWAR-433] Maven WAR plugin is deleting files generated by other plugins 
after upgrading to 3.3.0


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: outputTimestamp affects project's assemblies

[Hervé BOUTEMY]

Le samedi 11 juillet 2020, 20:38:28 CEST Lukasz Lenart a écrit :
> On 2020/07/11 17:38:32, Lukasz Lenart  wrote:
> > As far I understood, I must define the property with a value "now" as
> > mentioned in the ticket [1]
> > 
> > [1] https://issues.apache.org/jira/browse/MRELEASE-1029
> 
> maven-jar-plugin doesn't accept "now" value :\
as stated in 
https://maven.apache.org/guides/mini/guide-reproducible-builds.html, you put an 
explicit value once, and it will be updated 
automatically my maven-release-plugin: you won't need to to anything

I'll update the page, eventually removing the link to the Jira issue, to make 
clear that you don't need to do anything: the maven-release-plugin will do the 
job

> 
> Regards
> Łukasz
> 
> 
> -
> 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: mismatch between maven-release-plugin site and available artifacts

[Hervé BOUTEMY]

yes, sorry, I published 3.0.0-M2 release site, but I forgot that the release 
had been cancelled...

will revert to the current effective release = 3.0.0-M1

Regards,

Hervé

Le vendredi 10 juillet 2020, 15:17:26 CEST Mark Prins a écrit :
> There is a mismatch between the published site and the available artifact.
> 
> https://maven.apache.org/maven-release/maven-release-plugin/index.html
> lists 3.0.0-M2 published 2020-04-07 as the current release, but it
> cannot be downloaded from eg.
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-> 
> plugin/
> 
> can anyone resolve this?
> 
> TIA, Mark
> 
> -
> 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: outputTimestamp affects project's assemblies

[Hervé BOUTEMY]

as written in the documentation [2], you just need to add the property in your 
root POM, and maven-release-plugin (if upgraded to 3.0.0-M1) will take care of 
updating its value during release

I'm interested in any update in the doc to make this more clear, given it 
seems it is not yet

Regards,

Hervé

Le mercredi 8 juillet 2020, 08:10:22 CEST Lukasz Lenart a écrit :
> Hi,
> 
> I used to prepared a new test build for Apache Struts 2.5.23 and one of our
> committers noticed that the timestamps in the assemblies (zip files with
> libs, src, etc) have been set to a strange date from January. After
> investigating further we found the core issue [1] - as we use Apache Master
> Pom ver. 22 and we do not set outputTimestamp in project's parent pom, the
> value was inherited from [1].
> 
> My question is: what should we do? Do we need to manually set the
> outputTimestamp each time we are preparing a build as shown here [2]? Is
> there a way to generate this timestamp automatically when a new release is
> prepared and tagged?
> 
> [1] https://github.com/apache/maven-apache-parent/blob/apache-22/pom.xml#L95
> [2] https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> 
> Thanks in advance
> Łukasz
> 
> -
> 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: Maven moving to the next level: the build/consumer pom

[Hervé BOUTEMY]

I just created a "buildconsumer" branch in Doxia [1] to have a live example of 
the new simplified build POM that Maven 3.7.0 will allow [2]

As expected, this branch can't build with Maven 3.6.3, but can with Maven 
3.7.0-SNAPSHOT.
And in my favorite IDE, as expected, dependency resolution does not work 
because of missing info in pom.xml (which is now a build pom, with removed 
tags, then was not a valid POM until now)

What is expected is IDE maintainers to check what they need to do at IDE level 
to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.

Regards,

Hervé

[1] https://github.com/apache/maven-doxia/tree/buildconsumer

[2] 
https://github.com/apache/maven-doxia/commit/15e3de1a97bf48a394cb566783cac851c0728d98

Le samedi 4 juillet 2020, 07:35:37 CEST Jaroslav Tulach a écrit :
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
> your issue as a bug report? E.g. have you tried to use your new Maven with
> NetBeans and did you face a problem? Having steps to reproduce would make
> it more real for the NetBeans community to take action.
> 
> -jt
> 
> po 22. 6. 2020 v 23:18 odesílatel Robert Scholte 
> 
> napsal:
> > Hi,
> > 
> > One of my long standing wishes has made it to the master branch of Maven:
> > the support for build/consumer pom.
> > With this we can finally start improving the pom without breaking the
> > Maven eco system.
> > 
> > Up until now the pom.xml has been distributed (installed/deployed) as is
> > to both local and remote repositories.
> > The good thing is that is it fast and there is no magic.
> > However, it sometimes implies adding redundant information and it also
> > blocks any chance of improvement for Maven
> > 
> > The challenge is to make it possible to have an locally an improved
> > "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
> > 
> > The whole architecture of Maven was built upon an immutable pom.xml, so it
> > took a while to split this, but I managed to solve this.
> > And to confirm that it works, some transformations have been added for the
> > next Maven release
> > The local pom it still model 4.0.0 compatible, but some redundant elements
> > are not required anymore.
> > - in case the  is located at its relativePath (default:
> > ../pom.xml), the version can be removed. groupId and artifactId are still
> > required to ensure it is being matched with the right parent.
> > 
> > - dependencies that are part of the reactor don't need a version anymore
> > These are implemented steps to get from the file model to the raw model,
> > where the required versions are added.
> > 
> > When distributing the pom, the previous transformations are done, but
> > also:
> > - cifriendly placeholders in versions (${sha1}, ${revision},
> > ${changelist}) will be resolved.
> > -  from  will be removed
> > -  from  will be removed
> > These cleanups are context aware, if they appear in some configuration,
> > they won't be touched.
> > One of our integration-tests[1] demonstrates how new poms in a multimodule
> > project might look like.
> > 
> > Even though the latter steps look quite small (removing elements with
> > relative paths), it should give us enough feedback about the whole
> > process.
> > 
> > The status is that it is ready to be embedded in supporting tools like
> > IDEs.
> > We should give them time to work on this and share feedback.
> > It might require some adjustments in Maven to improve user experience.
> > 
> > In the meantime we need to work on plugins that will have impact by these
> > changes.
> > Most significant is are signing maven plugins such as the
> > maven-gpg-plugin, which needs to work with the distributed pom instead of
> > the local pom.
> > Also all packaging plugin that can include the pom.xml and pom.properties
> > in their archive should switch to the distributed pom.
> > The maven-shade-plugin was marked as well, but at first glance this looks
> > fine.
> > In the end all our plugins must be verified, just to be sure.
> > So there's enough to work on.
> > 
> > In general I avoid giving timelines about how fast a new release will be
> > available.
> > Due to the overhead, the small amount of available time of the few
> > volunteers working on Maven, I prefer to have a worth set of changes.
> > In this case the impact of the changes can be huge, and I want to have
> > enough faith that we won't introduce irreversible mistakes.
> > Don't expect a new official release in the 3 next months, however we might
> > have alpha or beta releases.
> > 
> > There is a wiki page that explains this topic in more detail[2]
> > It is still a draft, as there are still parts where we need to reach
> > consensus.
> > This page is intended as a base for discussions by Maven developers, users
> > and related projects, such as IDEs, Repository Managers, CI Servers, etc.
> > 
> > Looking forward for any 

Re: org.codehaus.mojo > mojohaus.org

[Hervé BOUTEMY]

Le mardi 30 juin 2020, 15:27:37 CEST Charles Herrick a écrit :
> Thanks Greg, those urls do indeed resolve.
> 
> We are left with urls in the Maven online documentation that still have the
> old org.codehaus.mojo forms that do NOT resolve.
 
> Do we have a plan to edit these links in the documentation?
please point us to the pages containing the old links so we can fix what has 
not yet been fixed

Regards,

Hervé

> 
> e: charles.herr...@perficient.com
> t: Texas Time
> --
> Charles Herrick,  Technical Architect
> m: 512-289-0926 | NASDAQ: PRFT | Perficient.com
> 
> 
> -Original Message-
> From: Greg Chabala  
> Sent: Monday, June 29, 2020 5:25 PM
> To: Maven Users List 
> Subject: Re: org.codehaus.mojo > mojohaus.org
> 
> Never used it myself, but these might help:
> 
> https://linkcheck.perficient.com/?url=https%3A%2F%2Fsearch.maven.org%2Fsearc
> h%3Fq%3Dg%3Aorg.codehaus.mojo%2520a%3Aanimal-sniffer=1295=charles.he
> rrick%40perficient.com=1593469532=7119cc9d-ba57-11ea-b7ff-9914abf9
> d899=ffac72ad *
 
> https://linkcheck.perficient.com/?url=https%3A%2F%2Fwww.mojohaus.org%2Fanima
> l-sniffer%2Fanimal-sniffer-maven-plugin%2F=1295=charles.herrick%40pe
> rficient.com=1593469532=7119cc9d-ba57-11ea-b7ff-9914abf9d899=03d
> 99ae5 
 
> https://linkcheck.perficient.com/?url=https%3A%2F%2Fgithub.com%2Fmojohaus%2F
> animal-sniffer=1295=charles.herrick%40perficient.com=1593469532&
> msgid=7119cc9d-ba57-11ea-b7ff-9914abf9d899=340b712f 
 
> Cheers,
> Greg Chabala
> 
> On Mon, Jun 29, 2020 at 4:54 PM Charles Herrick <
> charles.herr...@perficient.com> wrote:
 
> 
> > Links still have the old org.codehaus.mojo form URL and thus are not 
> > reachable. I’m looking for the latest Animal Sniffer to plug into my
> > Maven+Eclipse.
> >
> >
> >
> >
> >
> > Am I missing something?
> >
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> > e: charles.herr...@perficient.com
> >
> >
> >
> > t: Texas Time
> >
> >
> >
> > --
> >
> >
> >
> > *Charles Herrick*,  Technical Architect
> >
> >
> >
> > m: 512-289-0926 | NASDAQ: PRFT | *Perficient.com
> >  > %2F=1295=charles.herrick%40perficient.com=1593469532
> > =7119cc9d-ba57-11ea-b7ff-9914abf9d899=08d4d972 >*
> >
> >
> >
> >
> >
> > [image: Logo Icon] 
> >  > %2F=1295=charles.herrick%40perficient.com=1593469532
> > =7119cc9d-ba57-11ea-b7ff-9914abf9d899=08d4d972 >
> >
> >
> >
> >
> >
> > [image: LinkedIn Icon]
> >  > ompany%2F165444=1295=charles.herrick%40perficient.com=15934695
> > 32=7119cc9d-ba57-11ea-b7ff-9914abf9d899=56801d87 >   [image:
> > Twitter Icon]
> >  > ient=1295=charles.herrick%40perficient.com=1593469532=71
> > 19cc9d-ba57-11ea-b7ff-9914abf9d899=a09f1b35 >  ​[image: Blog Icon]
> >  > 2F=1295=charles.herrick%40perficient.com=1593469532=7119
> > cc9d-ba57-11ea-b7ff-9914abf9d899=b796ccbf >   [image: Facebook Icon]
> >  > erficient=1295=charles.herrick%40perficient.com=1593469532
> > id=7119cc9d-ba57-11ea-b7ff-9914abf9d899=83999dcb >   [image: YouTube
> > Icon]
> >  > Fchannel%2FUCRUC3AbkGIH4Wud_PgKovug%2F=1295=charles.herrick%40
> > perficient.com=1593469532=7119cc9d-ba57-11ea-b7ff-9914abf9d8
> > 99=96bf08dd >
> >
> >
> >
> >





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: (Negative) impact of Jansi

[Hervé BOUTEMY]

Le lundi 29 juin 2020, 23:11:09 CEST Falko Modler a écrit :
> > on crashes, I don't have any clue: details welcome
> 
> I see what I can do but please don't expect anything.
> 
> > see https://github.com/fusesource/jansi/pull/150
> > 
> > If we have multiple people using Windows to help test and improve this, we
> > could probably finally merge the update
> 
> I'll try to support.
thank you

> 
> But apart from that improvement, wouldn't passthrough _still_ have less
> overhead?
sure

> I mean, why even have it handled by Jansi at all when the shell itself
> can handle the sequences?
Windows shell can't handle ANSI escape code: that's the purpose of Jansi, and 
what is represented in JAnsi front page http://fusesource.github.io/jansi/

What makes you say that a Windows shell can handle the sequences?

Regards,

Hervé

> 
> Cheers,
> Falko
> 
> Am 29.06.2020 um 07:42 schrieb Hervé BOUTEMY:
> > on crashes, I don't have any clue: details welcome
> > 
> > but on the performance impact of Jansi on Windows (to detect ANSI codes)
> > when there is much content (like with Surefire output), there is some
> > partial work started to improve by removing flush:
> > see https://github.com/fusesource/jansi/pull/150
> > 
> > If we have multiple people using Windows to help test and improve this, we
> > could probably finally merge the update
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 28 juin 2020, 19:29:11 CEST Falko Modler a écrit :
> >> Hi everyone!
> >> 
> >> I recently ran into problems when trying to get colored log output from
> >> Quarkus tests (via Surefire):
> >> https://github.com/fusesource/jansi/issues/171
> >> 
> >> Coincidentally, we started seeing Surefire JVM fork crashes on various
> >> Windows 10 workstations when Jansi was active (sorry, I do not have more
> >> details at the moment).
> >> 
> >> I also found out that building Quarkus (651 modules) is 40% faster with
> >> -Djansi.passthrough=true (using Git Bash on Windows 10 & TERM=cygwin,
> >> and I guess also with xterm-256color).
> >> 
> >> Given these three observations, I am wondering whether it would be
> >> better if Maven actively used -Djansi.passthrough=true for TERM variants
> >> that are known to handle coloring on their own?
> >> Or at least document this?
> >> 
> >> Best regards,
> >> 
> >> Falko
> >> 
> >> 
> >> -
> >> 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





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: (Negative) impact of Jansi

[Hervé BOUTEMY]

on crashes, I don't have any clue: details welcome

but on the performance impact of Jansi on Windows (to detect ANSI codes) when 
there is much content (like with Surefire output), there is some partial work 
started to improve by removing flush:
see https://github.com/fusesource/jansi/pull/150

If we have multiple people using Windows to help test and improve this, we 
could probably finally merge the update

Regards,

Hervé

Le dimanche 28 juin 2020, 19:29:11 CEST Falko Modler a écrit :
> Hi everyone!
> 
> I recently ran into problems when trying to get colored log output from
> Quarkus tests (via Surefire): https://github.com/fusesource/jansi/issues/171
> 
> Coincidentally, we started seeing Surefire JVM fork crashes on various
> Windows 10 workstations when Jansi was active (sorry, I do not have more
> details at the moment).
> 
> I also found out that building Quarkus (651 modules) is 40% faster with
> -Djansi.passthrough=true (using Git Bash on Windows 10 & TERM=cygwin,
> and I guess also with xterm-256color).
> 
> Given these three observations, I am wondering whether it would be
> better if Maven actively used -Djansi.passthrough=true for TERM variants
> that are known to handle coloring on their own?
> Or at least document this?
> 
> Best regards,
> 
> Falko
> 
> 
> -
> 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: Access or generate a classpath for dependency not in any scope but attached to plugin.

[Hervé BOUTEMY]

the Maven Checkstyle Plugin source code is here:
https://github.com/apache/maven-checkstyle-plugin/
with links to CI and issue tracking

IMHO, updating its code should be easier than trying to tweak scripting with 
Ant run.
And with the integration tests (in src/its, launched with "mvn -Prun-its 
verify"), you could easily check that your new feature has expected results

then provide us a Pull Requests, to get the new feature integrated into the 
official plugin, and become a new Maven contributor!

If you're interested, we're having an online "Hack Commit Push" event 
tomorrow, where I will be there the whole day (Paris timezone) to help people 
wanting to contribute:
see https://paris2020.hack-commit-pu.sh/

Regards,

Hervé

Le vendredi 26 juin 2020, 03:21:33 CEST LINUS FERNANDES a écrit :
> While the exec maven plugin will satisfy the reduced classpath
> requirements, I'm constricted by the requirement of the Checkstyle CLI that
> requires a list of source files as a parameter to be passed; it doesn't
> accept a directory and maven apparently works best with directories.
> There appears to be no maven plugin that lists source files and while I can
> construct the list of source files via Ant Run plugin, I cannot propagate
> the dynamically added property to the exec maven plugin.
> Any suggestions?
> 
> Or should I revert to the original all Ant version?
> 
> 
> 
> On Thu, 25 Jun 2020, 19:51 LINUS FERNANDES, 
> 
> wrote:
> > I think exec maven plugin might need my requirements better of not adding
> > Checkstyle jars to the project's dependencies. I'll have to test that out,
> > though.
> > 
> > On Thu, 25 Jun 2020, 14:33 LINUS FERNANDES, 
> > 
> > wrote:
> >> I've raised a feature request at
> >> https://issues.apache.org/jira/browse/MCHECKSTYLE-396
> >> 
> >> Regards,
> >> Linus.
> >> 
> >> 
> >> 
> >> 
> >> On Thu, 25 Jun 2020, 14:19 LINUS FERNANDES, 
> >> 
> >> wrote:
> >>> Thanks, that resolves the issue with running the goal as
> >>> antrun:run@checkstyleg.
> >>> 
> >>> Regards,
> >>> Linus.
> >>> 
> >>> On Thu, 25 Jun 2020, 13:39 Benjamin Marwell,  wrote:
>  Feature requests can be created here:
>  https://issues.apache.org/jira/projects/MCHECKSTYLE
>  
>  You are welcome to create a pull request.
>  
>  Looking at the ant configuration, you could just use the plugin
>  classpath in your java task:
>  
>  https://maven.apache.org/plugins/maven-antrun-plugin/examples/classpath
>  s.html
>  
>  
>  Am Do., 25. Juni 2020 um 09:16 Uhr schrieb LINUS FERNANDES
>  
>  :
>  > I would like to create a feature request---evidently.
>  > 
>  > This is something that impacts the ant and Gradle tasks as well.
>  > 
>  > I'm not sure where to make this request.
>  > 
>  > Should it be on the Checkstyle Github repo or will I have to make
>  
>  three
>  
>  > separate requests, one for each of the above?
>  > 
>  > The feature is available on the CLI using the -g option.
>  > 
>  > I intend to use this during the Maven build, not from my code.
>  > 
>  > Since I already had Ant configured to do exactly that, I preferred to
>  
>  use
>  
>  > the Ant Run plugin to reproduce the functionality within Maven.
>  > 
>  > The pom file is located at:
>  > 
>  > https://github.com/Fernal73/DSAlgos/blob/master/pom.xml
>  > 
>  > I have no interest in creating my own plugin given the attendant
>  
>  issues of
>  
>  > maintaining it and for just this feature.
>  > 
>  > This should really be part of the Maven, Ant and Gradle
>  
>  configurations.
>  
>  > Perhaps, it's because the feature is still considered experimental
>  > and
>  > there's no pressure from users to add the ability to generate Xpath
>  > suppressions in the other ways to use Checkstyle.
>  > 
>  > I find it very useful, though although it's complicated to set it up
>  
>  in its
>  
>  > current Avatar.
>  > 
>  > Regards,
>  > Linus.
>  > 
>  > 
>  > 
>  > 
>  > On Thu, 25 Jun 2020, 11:56 Benjamin Marwell, 
>  
>  wrote:
>  > > Well, you could write your own plugin which has checkstyle as a
>  
>  dependency.
>  
>  > > But it might be the easiest to just create a PR for the checkstyle
>  
>  plugin.
>  
>  > > The checkstyle plugin is maintained by maven. So why not just
>  
>  create a
>  
>  > > feature request?
>  > > 
>  > > Also, where do you want to execute the "new goal"? In the maven
>  
>  build
>  
>  > > or inside your java code? This will also make a difference.
>  > > If it is the latter, you can just pull in the plugin as a regular
>  > > dependency.
>  > > You can make it optional or provided (or both) if you do not need
>  
>  it at
>  
>  > > 

[ANN] Apache Maven Site Plugin 3.9.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Site Plugin, version 3.9.1

This plugin is used to generate a site for the project. The generated site also 
includes the project's reports that were configured in the POM.

https://maven.apache.org/plugins/maven-site-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-site-plugin
  3.9.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-site-plugin/download.cgi

Release Notes - Maven Site Plugin - Version 3.9.1

** Bug
* [MSITE-856] - NullPointer on 
org.apache.maven.plugins.site.render.SiteMap.relativePath
* [MSITE-863] - NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when 
running reports with Maven versions < 3.6.1

** Improvement
* [MSITE-845] - Drop Maven 2 support
* [MSITE-862] - log Doxia source when rendering with site:run

** Task
* [MSITE-757] - drop Maven 2 support


Enjoy,

-The Apache Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Reporting Exec 1.5.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Reporting Exec, version 1.5.1

This component provides an API to prepare report plugins execution with Maven 3.

https://maven.apache.org/shared/maven-reporting-exec/

You can download the appropriate sources etc. from the download page:

https://maven.apache.org/shared/maven-reporting-exec/download.cgi


Release Notes - Maven Shared Components - Version maven-reporting-exec-1.5.1

** Bug
* [MSHARED-923] - upgrade maven-shade-plugin to 3.2.4 to get Reproducible 
Build
* [MSHARED-924] - fix Xpp3DomUtils shading relocation
* [MSHARED-921] - NoSuchMethodError: 'Xpp3Dom.getInputLocation()' with 
Maven versions < 3.6.1

** Improvement
* [MSHARED-814] - Require Java 7
* [MSHARED-879] - make build Reproducible

** Task
* [MSHARED-663] - mark ReportPlugin and ReportSet package private


Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven EJB Plugin 3.1.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven EJB 
Plugin, version 3.1.0

This plugin generates a Java Enterprise JavaBean (EJB) file as well as the 
associated client JAR.

https://maven.apache.org/plugins/maven-ejb-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-ejb-plugin
  3.1.0



Release Notes - Apache Maven EJB Plugin - Version 3.1.0

Improvement
* [MEJB-129] Refactor IncludesExcludes to reduce code duplication
* [MEJB-126] make build Reproducible

New Feature
* [MEJB-128] Reproducible Builds: make entries in output jar files reproducible 
(order + timestamp)


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Maven WAR Plugin 3.3.0 Released

[Hervé BOUTEMY]

Hello,

No: please open a Jira issue with sample project, expected + effective result 
so we can fix and add an IT to avoid future regressions

Regards,

Hervé

Le mercredi 10 juin 2020, 10:15:07 CEST Maxim Solodovnik a écrit :
> Hello,
> 
> I just have switched from 3.2.3 to this new version and it seems
> https://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html#archive
> Classes Is not working anymore :(
> 
> Is it intended?
> 
> On Tue, 9 Jun 2020 at 18:43, Hervé Boutemy  wrote:
> > The Maven team is pleased to announce the release of the Apache Maven WAR
> > Plugin, version 3.3.0
> > 
> > This plugin builds a Web Application Archive (WAR) file from the project
> > output and its dependencies.
> > 
> > https://maven.apache.org/plugins/maven-war-plugin/
> > 
> > You should specify the version in your project's plugin configuration:
> > 
> > 
> > 
> >   org.apache.maven.plugins
> >   maven-war-plugin
> >   3.3.0
> > 
> > 
> > 
> > 
> > Release Notes - Apache Maven WAR Plugin - Version 3.3.0
> > 
> > Bug
> > * [MWAR-429] Failed to execute goal
> > org.apache.maven.plugins:maven-war-plugin:3.2.3:exploded
> > (pre-exploded-war)
> > on project alfresco-platform
> > * [MWAR-427] WAR plugin includes the same artifact twice if used without
> > clean
> > * [MWAR-314] failOnMissingWebXml ignored when webXml set
> > 
> > Improvement
> > * [MWAR-431] make build Reproducible
> > * [MWAR-430] support JakartaEE namespace: remove or adapt hardcoded
> > reference to javax.servlet package
> > * [MWAR-375] Remove the useCache with its implementation
> > 
> > New Feature
> > * [MWAR-432] Reproducible Builds: make entries in output jar files
> > reproducible (order + timestamp)
> > 
> > 
> > Enjoy,
> > 
> > -The Maven team
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven WAR Plugin 3.3.0 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven WAR 
Plugin, version 3.3.0

This plugin builds a Web Application Archive (WAR) file from the project output 
and its dependencies.

https://maven.apache.org/plugins/maven-war-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-war-plugin
  3.3.0



Release Notes - Apache Maven WAR Plugin - Version 3.3.0

Bug
* [MWAR-429] Failed to execute goal 
org.apache.maven.plugins:maven-war-plugin:3.2.3:exploded (pre-exploded-war) on 
project alfresco-platform
* [MWAR-427] WAR plugin includes the same artifact twice if used without clean
* [MWAR-314] failOnMissingWebXml ignored when webXml set

Improvement
* [MWAR-431] make build Reproducible
* [MWAR-430] support JakartaEE namespace: remove or adapt hardcoded reference 
to javax.servlet package
* [MWAR-375] Remove the useCache with its implementation

New Feature
* [MWAR-432] Reproducible Builds: make entries in output jar files reproducible 
(order + timestamp)


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Shade Plugin 3.2.4 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Shade 
Plugin, version 3.2.4

This plugin repackages the project classes together with their dependencies 
into a single uber-jar, optionally renaming classes  or removing unused classes.

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.2.4



Release Notes - Apache Maven Shade Plugin - Version 3.2.4

Bug
* [MSHADE-363] Breaking change to ResourceTransformer's API
* [MSHADE-360] ServicesResourceTransformer.modifyOutputStream swallows 
IOExceptions

Task
* [MSHADE-365] document Properties transformers available since 3.2.2 in 
separate table
* [MSHADE-364] Don't log as duplicate resource handled by a transformer


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't copy open Excel spreadsheet

[Hervé BOUTEMY]

Le vendredi 24 avril 2020, 19:43:02 CEST Evan Ross a écrit :
> I have an Excel spreadsheet in my resources and find that my maven build
> vailes with “The process cannot access the file because it is being used by
> another process” when the sheet is open in Excel.
I don't have easily access to a situation to test: can you share the full 
stacktrace, please?

> 
> I had a similar issue in my app until I changed the opening of the sheet to
> be read-only.
can you show precisely which API you were using in your app to open the file 
and how you modified the call, please?

> 
> It would seem that the maven-resources-plug has the same issue. It should be
> changed to use a read-only open of the source files that are to be copied.
yes, if we can do it, it would be nice

> 
> Sent from Mail for Windows
> 10





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: override Checkstyle resources config

[Hervé BOUTEMY]

for reference, useful discussion on dev@maven of:
- plugins read-only parameters, per plugin conception,
- Maven 3.x bug that allows configuring such supposed read-only parameter (was 
properly forbidden in Maven 2)
- this Maven core bug will be fixed in future Maven 3.7.0
- then some builds using the bug will break, and people will have to work with 
plugin developers to eventually add new features around the read-only parameter 
if it was a missing feature

see detailed discussion in 
https://lists.apache.org/thread.html/rf16612451ece2b2fcdd678d06cc6dad9b687f5d9cfba11ae66b12137%40%3Cdev.maven.apache.org%3E

Regards,

Hervé

Le jeudi 23 avril 2020, 19:44:08 CEST Javier Gómez a écrit :
> Any thoughts on this?
> 
> We don't want to define this spefic folders config in POM build
>  block,  to avoid inherit that in child POMs.
> But we want that they were analyzed by checkstyle plugin, so we are
> forcing that  at the plugin level, specifying the  block.
> 
> That this is a read-only attribute, and we define it in the plugin
> configuration, does not imply that the compilation fails, as I would
> expect. Is this correct?
> 
> Thanks in advance.
> 
> Javier
> 
> On 2020/04/20 18:34:23, Javier Gómez wrote:
>  > Hello all,>
>  > 
>  > We are trying to run Checkstyle plugin over a group of resource
> 
> files, located in various directories outside standard directory layout,
> in project root folder,>
> 
>  > /module1>
>  > src/main/java>
>  > src/main/resources>
>  > pom.xml>
>  > /module2>
>  > ...>
>  > /src>
>  > /DIR1>
>  > /DIR2>
>  > pom.xml>
>  > 
>  > To do this, the best way we found, was configure execution of
> 
> checkstyle plugin in parent POM,>
> 
>  > and set this directories as resources in checkstyle plugin >
>  > 
>  > 
>  > org.apache.maven.plugins>
>  > maven-checkstyle-plugin>
>  > false>
>  > 
>  > 
>  > 
>  > dir1>
>  > 
>  > 
>  > dir2>
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > I know that the *resources* attribute is defined *readonly*, but this
> 
> configuration works, and the resources in this directories are analyzed.>
> 
>  > Is there any possible side effect with this ?>
>  > The modules in project inherits a checkstyle configuration from
> 
> parent *pluginManagement* that is not affected by this hack.>
> 
>  > Regards>
>  > 
>  > 
>  > Javier>





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Customizing the maven-site-plugin Markdown renderer?

[Hervé BOUTEMY]

sorry, I had a look and wanted to take time to have a minimal Maven site 
generation to compare with your direct test: I just sent you a PR

your test is great to show the objective
my addition shows the current effective result = admonition markup is not 
detected, rendered as-is
I'm quite suprised that the markup is not detected, because 
flexmark-ext-amonition is a Doxia Markdown dependency:
https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-markdown/dependencies.html

I did not expect that the html would be rendered as wanted, but at least that 
the markup would have been detected and rendered in some html form

seems it's time to extend the sample to add a customised doxia-module-markdown 
:)

Regards,

Hervé

Le jeudi 16 avril 2020, 14:56:05 CEST Stephan Wissel a écrit :
> Did you have a chance to look at this?
> 
> On Thu, Apr 9, 2020 at 2:10 AM Stephan Wissel  wrote:
> > Hello Hervé,
> > 
> > I created a Flexmark sample that is as close as possible to the way
> > Flexmark is used in Doxia:
> > 
> > https://github.com/Stwissel/maven-site-extension/tree/master/simple-flexma
> > rk-example The result can be seen here:
> > https://projectcastle.io/sample.html
> > (I copied a site-plugin generated page and just removed the body part and
> > replace it with the markdown conversion result)
> > 
> > As it seems, to get Adminition working in the rendering, you need to add a
> > single line (and the import/dependency of course)
> > 
> > https://github.com/Stwissel/maven-site-extension/blob/master/simple-flexma
> > rk-example/src/main/java/com/notessensei/demo/Demo1.java#L78
> > 
> > Would you need more samples?
> > 
> > 
> > Create a nice day!
> > Stephan H. Wissel
> > 
> > Phone: +65 96673269
> > Blog <https://www.wissel.net/blog> Twitter
> > <http://twitter.com/notessensei> LinkedIn
> > <http://sg.linkedin.com/in/notessensei> Xing
> > <https://www.xing.com/profile/StephanH_Wissel>
> > 
> > 
> > On Mon, Apr 6, 2020 at 2:42 PM Hervé BOUTEMY 
> > 
> > wrote:
> >> don't hesitate to share every single concrete step, even the flexmark
> >> standalone test: this will ease working together, ensuring we understand
> >> each
> >> other
> >> 
> >> even before updating doxia-module-markdown with an updated version, there
> >> is a
> >> test with a Maven site to be done with the normal Doxia, to show the
> >> result
> >> (perhaps there is a partial failure only): this will be interesting to
> >> compare
> >> the result against the flexmark standalone test.
> >> 
> >> then once we'll be at updating doxia-module-markdown, yes, you can
> >> override
> >> the version used by the maven-site-plugin by setting dependencies in
> >> plugin
> >> definition
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le lundi 6 avril 2020, 07:12:14 CEST Stephan Wissel a écrit :
> >> > Sorry for not being clear. The GitHub part is easy.
> >> > What I'm not sure about is how I can test my modification in the
> >> 
> >> context of
> >> 
> >> > the site plugin.
> >> > Would defining my markdown renderer as dependency of the site plugin
> >> > overwrite the build in renderer or do I have to modify the source of
> >> > the
> >> > site plugin too?
> >> > 
> >> > Create a nice day!
> >> > Stephan H. Wissel
> >> > 
> >> > Phone: +65 96673269
> >> > Blog <https://www.wissel.net/blog> Twitter <
> >> 
> >> http://twitter.com/notessensei>
> >> 
> >> > LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> >> > <https://www.xing.com/profile/StephanH_Wissel>
> >> > 
> >> > On Mon, Apr 6, 2020 at 6:16 AM Hervé BOUTEMY 
> >> 
> >> wrote:
> >> > > you can create a GitHub repository, or a collection of repositories
> >> > > whatever is necessary
> >> > > 
> >> > > Regards,
> >> > > 
> >> > > Hervé
> >> > > 
> >> > > Le dimanche 5 avril 2020, 18:38:50 CEST Stephan Wissel a écrit :
> >> > > > I did a flexmark standalone test, happy to try to integrate that.
> >> > > > I presume I would define my local moxia modification (after mvn
> >> 
> >> clean
> >> 
> >> > > > install) as a site plugin depe

[ANN] Apache Maven AntRun Plugin 3.0.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
AntRun Plugin, version 3.0.0
 
This plugin provides the ability to run Ant tasks from within Maven. You can 
even embed your Ant scripts in the POM!
 
https://maven.apache.org/plugins/maven-antrun-plugin/
 
You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-antrun-plugin
  3.0.0

 
You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-antrun-plugin/download.cgi
 

Release Notes - Maven Antrun Plugin - Version 3.0.0

** Bug
* [MANTRUN-172] - Properties passed to Maven as -D don't get passed to 
 invocations when a profile sets the same property
* [MANTRUN-178] - Ignore precedence of mvn command line over property 
defined in  section
* [MANTRUN-179] - Seems impossible to use combine.* attributes with 
maven-antrun-plugin configuration
* [MANTRUN-181] - AttachArtifact task does not work in external Ant build 
file
* [MANTRUN-192] - filterArtifacts in DependencyFilesetsTask includes entire 
maven.local.repository
* [MANTRUN-204] - antrun loops the backing map of java.util.Properties 
withouth checking type safety
* [MANTRUN-205] - maven-antrun-plugin pages at maven.apache.org still have 
bad url codehaus references
* [MANTRUN-221] - Fails to pass maven properties set in user properties only

** Improvement
* [MANTRUN-201] - Migrate plugin to Maven 3.0
* [MANTRUN-202] - Fail the build when deprecated parameters tasks, 
sourceRoot or testSourceRoot are used
* [MANTRUN-217] - Require Java 7
* [MANTRUN-222] - make build Reproducible, upgrade maven-plugins pom to 34

** Task
* [MANTRUN-209] - Add documentation information for GitHub
* [MANTRUN-211] - Upgrade mave-surefire/failsafe-plugin 2.21.0

** Dependency upgrade
* [MANTRUN-203] - Upgrade to maven-plugins 30
* [MANTRUN-210] - Upgrade parent to 31
* [MANTRUN-212] - Upgrade plexus-utils 3.1.0
* [MANTRUN-213] - Upgrade plexus-utils 3.1.0
* [MANTRUN-214] - upgrade default Ant version to 1.9.14
* [MANTRUN-215] - Upgrade maven-plugins parent to version 32
* [MANTRUN-218] - Upgrade JUnit to 4.13
* [MANTRUN-219] - Upgrade XMLUnit to 2.6.4 (test dependency)
 
Enjoy,
 
-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Shade Plugin 3.2.3 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Shade Plugin, version 3.2.3
 
This plugin provides the capability to package the artifact in an uber-jar, 
including its dependencies and to shade - i.e. rename - the packages of some of 
the dependencies.
 
https://maven.apache.org/plugins/maven-shade-plugin/
 
You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-shade-plugin
  3.2.3

 
You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-shade-plugin/download.cgi
 
Release Notes - Maven Shade Plugin - Version 3.2.3

** Bug
* [MSHADE-352] - shaded jars are not reproducible when using transformer

** Dependency upgrade
* [MSHADE-355] - Java 15 Compatibility - JDependecny/ASM Upgrade
* [MSHADE-357] - Upgrade asm to 8.0
 
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: Customizing the maven-site-plugin Markdown renderer?

[Hervé BOUTEMY]

don't hesitate to share every single concrete step, even the flexmark 
standalone test: this will ease working together, ensuring we understand each 
other

even before updating doxia-module-markdown with an updated version, there is a 
test with a Maven site to be done with the normal Doxia, to show the result 
(perhaps there is a partial failure only): this will be interesting to compare 
the result against the flexmark standalone test.

then once we'll be at updating doxia-module-markdown, yes, you can override 
the version used by the maven-site-plugin by setting dependencies in plugin 
definition

Regards,

Hervé

Le lundi 6 avril 2020, 07:12:14 CEST Stephan Wissel a écrit :
> Sorry for not being clear. The GitHub part is easy.
> What I'm not sure about is how I can test my modification in the context of
> the site plugin.
> Would defining my markdown renderer as dependency of the site plugin
> overwrite the build in renderer or do I have to modify the source of the
> site plugin too?
> 
> Create a nice day!
> Stephan H. Wissel
> 
> Phone: +65 96673269
> Blog <https://www.wissel.net/blog> Twitter <http://twitter.com/notessensei>
> LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> <https://www.xing.com/profile/StephanH_Wissel>
> 
> On Mon, Apr 6, 2020 at 6:16 AM Hervé BOUTEMY  wrote:
> > you can create a GitHub repository, or a collection of repositories
> > whatever is necessary
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 5 avril 2020, 18:38:50 CEST Stephan Wissel a écrit :
> > > I did a flexmark standalone test, happy to try to integrate that.
> > > I presume I would define my local moxia modification (after mvn clean
> > > install) as a site plugin dependency?
> > > 
> > > Along those lines:
> > >
> > > 
> > > org.apache.maven.plugins
> > > maven-site-plugin
> > > ${maven.site.plugin.version}
> > > 
> > > 
> > > org.apache.maven.plugins
> > > doxia-module-markdown
> > > 1.9.1-stw
> > > 
> > > 
> > > 
> > > 
> > > Would that work for providing a demo?
> > > 
> > > Create a nice day!
> > > Stephan H. Wissel
> > > 
> > > Phone: +65 96673269
> > > Blog <https://www.wissel.net/blog> Twitter <
> > 
> > http://twitter.com/notessensei>
> > 
> > > LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> > > <https://www.xing.com/profile/StephanH_Wissel>
> > > 
> > > On Sun, Apr 5, 2020 at 10:11 PM Hervé BOUTEMY 
> > 
> > wrote:
> > > > nice work: dos it mean that you managed to have the rendering as
> > 
> > expected?
> > 
> > > > Can you create a little demo and share?
> > > > 
> > > > On making the extension configurable and easy to use, it will be
> > 
> > complex
> > 
> > > > from a
> > > > Maven Site Plugin perspective: its relationship with Doxia (the core
> > > > rendering
> > > > engine), Doxia Markdown Module (the markdown parser for Doxia), Doxia
> > > > Sitetools and Doxia Skins will bring some challenges
> > > > 
> > > > That's why we'll need ot go step by step: sharing a first result with
> > > > a
> > > > lot of
> > > > manual config first, then looking on improvement to replace manual
> > 
> > config
> > 
> > > > with
> > > > nice parameters
> > > > 
> > > > I would really love to add such extensions, I'll really need your help
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 3 avril 2020, 21:56:41 CEST Stephan Wissel a écrit :
> > > > > Hi Hervé,
> > > > > 
> > > > > thank you for your reply, appreciate your swift response.
> > > > > It seems to be a little more complex ;-) , but started easy (looked
> > 
> > like
> > 
> > > > 1
> > > > 
> > > > > line and 1 import)
> > > > > 
> > > > > Extensions are loaded like line 145 in the MarkdownParser.class:
> > > > > extensions.add(
> > > > > AdminitionExtension.create() );
> > > > > 
> > > > > I did a quick check on CSS/JS. When I put them in
> > > > > /src/site/resources/css
> > > > > and /src/site/resources/js, they get copied into the target site.
> > > > > Then I added  

Re: Customizing the maven-site-plugin Markdown renderer?

[Hervé BOUTEMY]

you can create a GitHub repository, or a collection of repositories
whatever is necessary

Regards,

Hervé

Le dimanche 5 avril 2020, 18:38:50 CEST Stephan Wissel a écrit :
> I did a flexmark standalone test, happy to try to integrate that.
> I presume I would define my local moxia modification (after mvn clean
> install) as a site plugin dependency?
> Along those lines:
> 
>
> org.apache.maven.plugins
> maven-site-plugin
> ${maven.site.plugin.version}
> 
> 
> org.apache.maven.plugins
> doxia-module-markdown
> 1.9.1-stw
> 
> 
> 
> 
> Would that work for providing a demo?
> 
> Create a nice day!
> Stephan H. Wissel
> 
> Phone: +65 96673269
> Blog <https://www.wissel.net/blog> Twitter <http://twitter.com/notessensei>
> LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> <https://www.xing.com/profile/StephanH_Wissel>
> 
> On Sun, Apr 5, 2020 at 10:11 PM Hervé BOUTEMY  wrote:
> > nice work: dos it mean that you managed to have the rendering as expected?
> > Can you create a little demo and share?
> > 
> > On making the extension configurable and easy to use, it will be complex
> > from a
> > Maven Site Plugin perspective: its relationship with Doxia (the core
> > rendering
> > engine), Doxia Markdown Module (the markdown parser for Doxia), Doxia
> > Sitetools and Doxia Skins will bring some challenges
> > 
> > That's why we'll need ot go step by step: sharing a first result with a
> > lot of
> > manual config first, then looking on improvement to replace manual config
> > with
> > nice parameters
> > 
> > I would really love to add such extensions, I'll really need your help
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 3 avril 2020, 21:56:41 CEST Stephan Wissel a écrit :
> > > Hi Hervé,
> > > 
> > > thank you for your reply, appreciate your swift response.
> > > It seems to be a little more complex ;-) , but started easy (looked like
> > 
> > 1
> > 
> > > line and 1 import)
> > > 
> > > Extensions are loaded like line 145 in the MarkdownParser.class:
> > > extensions.add(
> > > AdminitionExtension.create() );
> > > 
> > > I did a quick check on CSS/JS. When I put them in
> > > /src/site/resources/css
> > > and /src/site/resources/js, they get copied into the target site.
> > > Then I added   
> > > to the site.xml - which also worked. So the prerequites can be handled
> > > in
> > > the site.xml without the need to change any code.
> > > 
> > > However I wouldn't see just to load that one extra plugin always, more
> > 
> > like
> > 
> > > make it configurable. I see two approaches:
> > > - read the name of the plugins from a config setting and leave it to the
> > > user - with all consequences - which one they specify
> > > - pick one (for starters) and have a config true/false flag whether to
> > 
> > load
> > 
> > > it (default false)
> > > 
> > > The first might be the more flexible solution, but could add a can of
> > > (support) worms.
> > > 
> > > What do you think?
> > > 
> > > Create a nice day!
> > > Stephan H. Wissel
> > > 
> > > Phone: +65 96673269
> > > Blog <https://www.wissel.net/blog> Twitter <
> > 
> > http://twitter.com/notessensei>
> > 
> > > LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> > > <https://www.xing.com/profile/StephanH_Wissel>
> > > 
> > > On Sat, Apr 4, 2020 at 1:55 AM Hervé BOUTEMY 
> > 
> > wrote:
> > > > Hi Stefan,
> > > > 
> > > > The code for Markdown parsing and extensions activation is in Doxia
> > 
> > > > Markdown module:
> > https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-markdown/x
> > 
> > > > ref/org/apache/maven/doxia/module/markdown/MarkdownParser.html#L133
> > > > 
> > > > I don't really reviewed how extensions are really activated, but
> > > > having
> > > > now a quick look at this admonition one, I see that flexmark-java
> > 
> > explains
> > 
> > > > some prerequisites that have not been integrated in Doxia:
> > > > https://github.com/vsch/flexmark-java/wiki/Extensions#admonition
> > > > 
> > > > Then I suppose from the code that:
> > > > 1. adding admonition markup will create some html
> > > > 2. but the ren

Re: Customizing the maven-site-plugin Markdown renderer?

[Hervé BOUTEMY]

nice work: dos it mean that you managed to have the rendering as expected?
Can you create a little demo and share?

On making the extension configurable and easy to use, it will be complex from a 
Maven Site Plugin perspective: its relationship with Doxia (the core rendering 
engine), Doxia Markdown Module (the markdown parser for Doxia), Doxia 
Sitetools and Doxia Skins will bring some challenges

That's why we'll need ot go step by step: sharing a first result with a lot of 
manual config first, then looking on improvement to replace manual config with 
nice parameters

I would really love to add such extensions, I'll really need your help

Regards,

Hervé

Le vendredi 3 avril 2020, 21:56:41 CEST Stephan Wissel a écrit :
> Hi Hervé,
> 
> thank you for your reply, appreciate your swift response.
> It seems to be a little more complex ;-) , but started easy (looked like 1
> line and 1 import)
> 
> Extensions are loaded like line 145 in the MarkdownParser.class:
> extensions.add(
> AdminitionExtension.create() );
> 
> I did a quick check on CSS/JS. When I put them in /src/site/resources/css
> and /src/site/resources/js, they get copied into the target site.
> Then I added   
> to the site.xml - which also worked. So the prerequites can be handled in
> the site.xml without the need to change any code.
> 
> However I wouldn't see just to load that one extra plugin always, more like
> make it configurable. I see two approaches:
> - read the name of the plugins from a config setting and leave it to the
> user - with all consequences - which one they specify
> - pick one (for starters) and have a config true/false flag whether to load
> it (default false)
> 
> The first might be the more flexible solution, but could add a can of
> (support) worms.
> 
> What do you think?
> 
> Create a nice day!
> Stephan H. Wissel
> 
> Phone: +65 96673269
> Blog <https://www.wissel.net/blog> Twitter <http://twitter.com/notessensei>
> LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> <https://www.xing.com/profile/StephanH_Wissel>
> 
> On Sat, Apr 4, 2020 at 1:55 AM Hervé BOUTEMY  wrote:
> > Hi Stefan,
> > 
> > The code for Markdown parsing and extensions activation is in Doxia
> > Markdown module:
> > 
> > https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-markdown/x
> > ref/org/apache/maven/doxia/module/markdown/MarkdownParser.html#L133
> > 
> > I don't really reviewed how extensions are really activated, but having
> > now a quick look at this admonition one, I see that flexmark-java explains
> > some prerequisites that have not been integrated in Doxia:
> > https://github.com/vsch/flexmark-java/wiki/Extensions#admonition
> > 
> > Then I suppose from the code that:
> > 1. adding admonition markup will create some html
> > 2. but the rendering will not be ok because prerequisites have not been
> > integrated
> > 3. and I fear that the issue will be more complex than these prerequisites
> > 
> > Then it's a full topic to investigate, create samples to test, look at
> > current result, then debug ot see what improvements are necessary
> > 
> > I personnally don't have time to work on this, but if a group start
> > working on this topic, I'd be happy to help
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 3 avril 2020, 16:31:49 CEST Stephan Wissel a écrit :
> > > Hi there,
> > > 
> > > We are using Markdown in our Maven generated site
> > > <http://maven.apache.org/plugins/maven-site-plugin/index.html>. Works
> > 
> > like
> > 
> > > a charm. AFAIK the plugin uses Flexmark
> > > <https://github.com/vsch/flexmark-java> under the hood, which supports
> > > the Admonition
> > > extensions
> > > <https://squidfunk.github.io/mkdocs-material/extensions/admonition/>.
> > > 
> > > We would like to use them too, the infoboxes are quite helpful for
> > > documentation. Our site configuration in the pom.xml looks like this:
> > > 
> > > 
> > > 
> > > org.apache.maven.plugins
> > > maven-site-plugin
> > > 3.8.2
> > > 
> > > How could we configure it to recognise the additional markdown?
> > 
> > > Also can be found here:
> > https://stackoverflow.com/questions/61001709/maven-site-generation-using-a
> > dv> 
> > > anced-markdown
> > > 
> > > Create a nice day!
> > > Stephan H. Wissel
> > > 
> > > Phone: +65 96673269
> > > Blog <https://www.wissel.net/blog> Twitter <
> > 
> > http://twitter.com/notessensei>
> > 
> > > LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> > > <https://www.xing.com/profile/StephanH_Wissel>
> > 
> > -
> > 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: Customizing the maven-site-plugin Markdown renderer?

[Hervé BOUTEMY]

Hi Stefan,

The code for Markdown parsing and extensions activation is in Doxia Markdown 
module:
https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-markdown/xref/org/apache/maven/doxia/module/markdown/MarkdownParser.html#L133

I don't really reviewed how extensions are really activated, but having now a 
quick look at this admonition one, I see that flexmark-java explains some 
prerequisites that have not been integrated in Doxia:
https://github.com/vsch/flexmark-java/wiki/Extensions#admonition

Then I suppose from the code that:
1. adding admonition markup will create some html
2. but the rendering will not be ok because prerequisites have not been 
integrated
3. and I fear that the issue will be more complex than these prerequisites

Then it's a full topic to investigate, create samples to test, look at current 
result, then debug ot see what improvements are necessary

I personnally don't have time to work on this, but if a group start working on 
this topic, I'd be happy to help

Regards,

Hervé

Le vendredi 3 avril 2020, 16:31:49 CEST Stephan Wissel a écrit :
> Hi there,
> 
> We are using Markdown in our Maven generated site
> . Works like
> a charm. AFAIK the plugin uses Flexmark
>  under the hood, which supports
> the Admonition
> extensions
> .
> 
> We would like to use them too, the infoboxes are quite helpful for
> documentation. Our site configuration in the pom.xml looks like this:
> 
> 
> org.apache.maven.plugins
> maven-site-plugin
> 3.8.2
> 
> How could we configure it to recognise the additional markdown?
> 
> Also can be found here:
> https://stackoverflow.com/questions/61001709/maven-site-generation-using-adv
> anced-markdown
> 
> Create a nice day!
> Stephan H. Wissel
> 
> Phone: +65 96673269
> Blog  Twitter 
> LinkedIn  Xing
> 





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Site Plugin 3.9.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Site Plugin, version 3.9.0
 
This plugin is used to generate a site for the project. The generated site also 
includes the project's reports that were configured in the POM.
 
https://maven.apache.org/plugins/maven-site-plugin/
 
You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-site-plugin
  3.9.0

 
You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-site-plugin/download.cgi
 
Release Notes - Maven Site Plugin - Version 3.9.0

** Bug
* [MSITE-847] - "$prerequisiteMavenVersion" text in plugin's documentation
* [MSITE-853] - Upgrade Doxia to 1.9.1 to have Markdown `code` and ``` 
support

** New Feature
* [MSITE-851] - Reproducible Builds: make entries in output jar files 
reproducible (order + timestamp)

** Improvement
* [MSITE-852] - Upgrade Doxia Site Renderer to 1.9.2 to remove Struts 
dependencies
* [MSITE-855] - make build Reproducible
 
Enjoy,
 
-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven DoxiaSitetools 1.9.2 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Doxia Sitetools, version 1.9.2
 
Doxia Sitetools is an extension of base Doxia component that generates either  
HTML sites, consisting of decoration and content that was generated by Doxia, 
or documents like RTF or PDF.

https://maven.apache.org/doxia/doxia-sitetools/

You can download the appropriate sources etc. from the download page:

https://maven.apache.org/doxia/doxia-sitetools/download.cgi
 
Release Notes - Maven Doxia Sitetools - Version 1.9.2

** Bug
* [DOXIASITETOOLS-216] - Broken link on doxia-site-renderer documentation 
index

** Improvement
* [DOXIASITETOOLS-218] - Make Doxia Sitetools build Reproducible

** Dependency upgrade
* [DOXIASITETOOLS-213] - Upgrade Maven Default Skin to 1.3
* [DOXIASITETOOLS-215] - avoid reporting plugins pulling in Struts 1.3.8 jar
* [DOXIASITETOOLS-217] - Upgrade JUnit to 4.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 Ant Tasks to Maven Artifact Resolver Ant Tasks - Calling Maven From Ant

[Hervé BOUTEMY]

I see multiple options:
- use Maven Ant Tasks for that
- use exec

Le vendredi 21 février 2020, 05:03:10 CET Tim N a écrit :
> Maven Ant Tasks had some support for calling Maven from Ant:
> https://maven.apache.org/ant-tasks/examples/mvn.html.
> 
> 
> Is there anything similar in Maven Artifact Resolver Ant Tasks or another
> project?





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven Ant Tasks - Central 501 HTTPS Required

[Hervé BOUTEMY]

Le mardi 18 février 2020, 03:00:44 CET Tim N a écrit :
> > maven-ant-tasks have been deprecated in favor of Maven Artifact Resolver
> 
> Ant Tasks: https://maven.apache.org/resolver-ant-tasks/
> 
> Fantastic, I'll give that a go. Is it possible to add a link to that
> project from https://maven.apache.org/ant-tasks/ ?

Good idea, I'll work on it



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org