Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Hervé Boutemy]

+1

Reproducible Build ok: reference build done with JDK 8 on Windows and umask = 
022 (parent POM not upgraded, which should remove the umask requirement)

Regards,

Hervé

Le dimanche 5 mai 2024, 21:29:12 CEST Michael Osipov a écrit :
> Hi,
> 
> we solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923
> rsion=12354123
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20res
> olution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2109/
> https://repository.apache.org/content/repositories/maven-2109/org/apache/mav
> en/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-re
> lease.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M14-source-release.zip
> sha512:
> cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f4
> 43c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

[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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven Shade Plugin version 3.5.3

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : zhongming hua, Olivier Lamy, Romain Manni-Bucau, Hervé Boutemy

PMC quorum reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.



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

[VOTE] Release Apache Maven Shade Plugin version 3.5.3

[Hervé Boutemy]

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12354342=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-2096/
https://repository.apache.org/content/repositories/maven-2096/org/apache/maven/plugins/maven-shade-plugin/3.5.3/maven-shade-plugin-3.5.3-source-release.zip

Source release checksum(s):
maven-shade-plugin-3.5.3-source-release.zip sha512: 
a97d291f66f7f4a96af936c27061305e3856cb1e32ee5130cbf9b2f9a31d2ac7c1551ab17cd41e75887ac2345b815fad248fb381f437bf1376467a4fcdf24544

Staging site:
https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven Plugin Tools version 3.12.0

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Sylwester Lachiewicz, Tamás Cservenák, Hervé Boutemy

PMC quorum: reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.



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

[RESULT] [VOTE] Release Apache Maven Source Plugin version 3.3.1

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Olivier Lamy, Tamás Cservenák, Sylwester Lachiewicz, Slawomir Jaranowski, 
Hervé Boutemy

PMC quorum: reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.



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

[RESULT] [VOTE] Release Apache Maven Artifact Plugin version 3.5.1

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Sylwester Lachiewicz, Slawomir Jaranowski, Tamás Cservenák, Hervé Boutemy

PMC quorum: reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.



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

[VOTE] Release Apache Maven Plugin Tools version 3.12.0

[Hervé Boutemy]

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12354176=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-2082/
https://repository.apache.org/content/repositories/maven-2082/org/apache/maven/plugin-tools/maven-plugin-tools/3.12.0/maven-plugin-tools-3.12.0-source-release.zip

Source release checksum(s):
maven-plugin-tools-3.12.0-source-release.zip sha512: 
605c9ca75303ffd595f2fab0c916e9cc13e7a5f7acee1cb7f399565c3d61cd2d63b70b0c6db713a829c8f8071af6b286073e113c3c7a3cffbbf68f745bde24b1

Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

[VOTE] Release Apache Maven Source Plugin version 3.3.1

[Hervé Boutemy]

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12353471=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-2081/
https://repository.apache.org/content/repositories/maven-2081/org/apache/maven/plugins/maven-source-plugin/3.3.1/maven-source-plugin-3.3.1-source-release.zip

Source release checksum(s):
maven-source-plugin-3.3.1-source-release.zip sha512: 
aaa76709d054491118546c8f67829aa9c8435b6b2e6e2577573ac049823d1ca2c54c730e4800291cd3756a677f75af0278be886d16e057cf88fc014991f0004f

Staging site:
https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

[VOTE] Release Apache Maven Artifact Plugin version 3.5.1

[Hervé Boutemy]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322=12353681=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-2078/
https://repository.apache.org/content/repositories/maven-2078/org/apache/maven/plugins/maven-artifact-plugin/3.5.1/maven-artifact-plugin-3.5.1-source-release.zip

Source release checksum(s):
maven-artifact-plugin-3.5.1-source-release.zip sha512: 
36054901ebb44f9a822fa3e6f93992df7735641601e153864379e76696ba67746357e18ad29d9f73da95e9fb699652a9b9f06d7cf48e8d77992f4d632150419f

Staging site:
https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: Revert commit 740dae43ca3ccf7692f37edf3184387e5666ca6b

[Hervé Boutemy]

Hi Konrad,

I saw the fork between Maven 3.9.x where I started the documentation job and 
Maven 4:

- Maven 3.9.x: https://github.com/apache/maven/pull/1444
as you can see, requiredMavenVersion exists since 3.0.2
https://issues.apache.org/jira/browse/MNG-4840

- Maven 4: https://github.com/apache/maven/pull/1445
yes, I had to merge and saw you did some improvements

AFAIK, in Maven 4, only requiredJavaVersion was added
what is not clear to me is that it seeems you updated the semantics fo 
requiredMavenVersion in plugin descriptor to be better

i see you found https://github.com/apache/maven/pull/1444 , let's continue the 
discussion here, as I don't know where the issue is yet, but sure, we need to 
clarify

Regards,

Hervé

Le lundi 25 mars 2024, 07:43:18 CET Konrad Windszus a écrit :
> Hi,
> I consider
> https://github.com/apache/maven/commit/740dae43ca3ccf7692f37edf3184387e5666
> ca6b wrong, as in fact the field requiredMavenVersion has been added quite
> recently and is only supported since Maven 4 (for details refer to
> https://issues.apache.org/jira/browse/MNG-7570). The referenced ticket
> https://issues.apache.org/jira/browse/MNG-4840 is only about the
> prerequisites section in the POM. Herve can you revert please? I propose to
> use PRs (even for changes like this) to prevent mistakes like this. Thanks,
> Konrad
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: release of maven-source-plugin

[Hervé Boutemy]

PR ready for review:
https://github.com/apache/maven-source-plugin/pull/24

I think it does the right job at differentiating 2 cases that the initial 
MSOURCES-121 merged too aggressively:
1. do not fail when executed twice with the same output file
2. but fail when re-attach happens to another output file = another classifier 
has to be configured

Regards,

Hervé

Le lundi 25 mars 2024, 07:31:53 CET Hervé Boutemy a écrit :
> IIUC, this is an explanation of the mystery failure that started the
> MSOURCE-121 update
> 
> but after MSOURCE-121, the plugin itself stops with a failure when detecting
> re-addition: that's why Gary can't upgrade, the failure is now happening at
> plugin level, and always
> "mvn install deploy" (with source enabled) is a simple test to see the
> failure introduced by MSOURCE-121
> 
> I'm starting to understand the many aspects of this issue: I think I know
> how to update the goal to be more tolerant
> 
> Thanks for the help
> 
> Hervé
> 
> Le dimanche 24 mars 2024, 20:39:55 CET Romain Manni-Bucau a écrit :
> > Hi,
> > 
> > I think it is fixed for v4 serie.
> > Main issue comes from the default v3 pom (
> > https://github.com/apache/maven/blob/maven-3.9.2/maven-model-builder/src/m
> > ai n/resources/org/apache/maven/model/pom-4.0.0.xml#L113) which is no more
> > a thing in v4 so the merge of the plugin executions does not happen the
> > same and the issue disappeared.
> > The easiest is likely to either let the default be merged and not use
> > "jar"
> > (implicit jar-no-fork instead) or just not use the default id
> > (attach-sources) and skip the default one.
> > 
> > So there is no source plugin issue (as the plugin will never fix it by
> > "bug
> > design") so no reason to hold a release IMHO.
> > 
> > Guess it silently overrided the already built artifact for years - until
> > we
> > just fail cause it is a broken design - after this change of goal
> > https://issues.apache.org/jira/browse/MNG-5940.
> > 
> > So long story short: we are on track and release can be done I think.
> > 
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau>> 
> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > 
> > <https://www.packtpub.com/application-development/java-ee-8-high-performan
> > ce
> > 
> > 
> > 
> > Le dim. 24 mars 2024 à 18:44, Gary Gregory  a
> > 
> > écrit :
> > > Hi All,
> > > 
> > > As long as https://issues.apache.org/jira/browse/MSOURCES-143 is in
> > > play, Commons will stay on a pre-3.3.0 version.
> > > 
> > > I re-read the comments, I still don't know what we can do in Commons
> > > to address this as this feels like some deep Maven Magic.
> > > 
> > > Gary
> > > 
> > > On Sun, Mar 24, 2024 at 11:48 AM Hervé Boutemy 
> > > 
> > > wrote:
> > > > I'd like to release maven-source-plugin 3.3.1 to drop the umask
> > > 
> > > sensitivity
> > > 
> > > > during Reproducible Builds :)1
> > > > 
> > > > but there are a few issues open
> > > > 
> > > >  https://issues.apache.org/jira/projects/MSOURCES/versions/12353471
> > > > 
> > > > they are related to https://issues.apache.org/jira/browse/
MSOURCES-121:
> > > I
> > > 
> > > > don't get what conditions made the build fail previously, but
> > > 
> > > MSOURCES-121
> > > 
> > > > make it fail now always.
> > > > Should we just change the ERROR into WARNING?
> > > > Should we do something smarter, for example not re-add if it's the
> > > > same
> > > 
> > > file?
> > > 
> > > > Or warn only if the second file addition is different from the first?
> > > 
> > > Then
> > > 
> > > > replace instead of add?
> > > > 
> > > > Please help clarifying and fixing this issue that seems ignored for a
> > > 
> > > long time
> > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > 
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: release of maven-source-plugin

[Hervé Boutemy]

IIUC, this is an explanation of the mystery failure that started the 
MSOURCE-121 update

but after MSOURCE-121, the plugin itself stops with a failure when detecting 
re-addition: that's why Gary can't upgrade, the failure is now happening at 
plugin level, and always
"mvn install deploy" (with source enabled) is a simple test to see the failure 
introduced by MSOURCE-121

I'm starting to understand the many aspects of this issue: I think I know how 
to update the goal to be more tolerant

Thanks for the help

Hervé

Le dimanche 24 mars 2024, 20:39:55 CET Romain Manni-Bucau a écrit :
> Hi,
> 
> I think it is fixed for v4 serie.
> Main issue comes from the default v3 pom (
> https://github.com/apache/maven/blob/maven-3.9.2/maven-model-builder/src/mai
> n/resources/org/apache/maven/model/pom-4.0.0.xml#L113) which is no more a
> thing in v4 so the merge of the plugin executions does not happen the same
> and the issue disappeared.
> The easiest is likely to either let the default be merged and not use "jar"
> (implicit jar-no-fork instead) or just not use the default id
> (attach-sources) and skip the default one.
> 
> So there is no source plugin issue (as the plugin will never fix it by "bug
> design") so no reason to hold a release IMHO.
> 
> Guess it silently overrided the already built artifact for years - until we
> just fail cause it is a broken design - after this change of goal
> https://issues.apache.org/jira/browse/MNG-5940.
> 
> So long story short: we are on track and release can be done I think.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
> Le dim. 24 mars 2024 à 18:44, Gary Gregory  a
> 
> écrit :
> > Hi All,
> > 
> > As long as https://issues.apache.org/jira/browse/MSOURCES-143 is in
> > play, Commons will stay on a pre-3.3.0 version.
> > 
> > I re-read the comments, I still don't know what we can do in Commons
> > to address this as this feels like some deep Maven Magic.
> > 
> > Gary
> > 
> > On Sun, Mar 24, 2024 at 11:48 AM Hervé Boutemy 
> > 
> > wrote:
> > > I'd like to release maven-source-plugin 3.3.1 to drop the umask
> > 
> > sensitivity
> > 
> > > during Reproducible Builds :)1
> > > 
> > > but there are a few issues open
> > > 
> > >  https://issues.apache.org/jira/projects/MSOURCES/versions/12353471
> > > 
> > > they are related to https://issues.apache.org/jira/browse/MSOURCES-121:
> > I
> > 
> > > don't get what conditions made the build fail previously, but
> > 
> > MSOURCES-121
> > 
> > > make it fail now always.
> > > Should we just change the ERROR into WARNING?
> > > Should we do something smarter, for example not re-add if it's the same
> > 
> > file?
> > 
> > > Or warn only if the second file addition is different from the first?
> > 
> > Then
> > 
> > > replace instead of add?
> > > 
> > > Please help clarifying and fixing this issue that seems ignored for a
> > 
> > long time
> > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

release of maven-source-plugin

[Hervé Boutemy]

I'd like to release maven-source-plugin 3.3.1 to drop the umask sensitivity 
during Reproducible Builds :)1

but there are a few issues open
 https://issues.apache.org/jira/projects/MSOURCES/versions/12353471

they are related to https://issues.apache.org/jira/browse/MSOURCES-121: I 
don't get what conditions made the build fail previously, but MSOURCES-121 
make it fail now always.
Should we just change the ERROR into WARNING?
Should we do something smarter, for example not re-add if it's the same file? 
Or warn only if the second file addition is different from the first? Then 
replace instead of add?

Please help clarifying and fixing this issue that seems ignored for a long time

Regards,

Hervé



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

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

Le lundi 26 février 2024, 13:42:19 CET Ceki Gulcu a écrit :
> Hello Bernd,
> 
> I was unaware of the capabilities of the release flag. Thank you for
> explaining.

a proof that even capabilities like --release flag from JDK 9 (JEP 247 https://
openjdk.org/jeps/247) need to be promoted because it's not sufficiently known



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

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

Le mardi 27 février 2024, 13:32:36 CET Elliotte Rusty Harold a écrit :
> Toolchains support using JDK 8 to compile even though JDK 17 is
> executing Maven, which does handle this. Unfortunately toolchains are
> poorly designed, badly documented, and not widely understood within
> the community. I'm trying to improve some of the docs for toolchains,
> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.

+1 (taking apart the "poorly designed" aspect)

that's why toolchain improvement is one necessary enabler

another one is plugins prerequisites history

in the whole discussion, I did not find any other enabler: please chime in if 
you saw one



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

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

Le mardi 27 février 2024, 18:33:43 CET sebb a écrit :
> On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell  wrote:
> > > Compiling for Java 8 with
> > > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > > They do not produce the same byte code.
+1 that's a fact

> > > There is a need to compile *with* JDK 8, not just compile *for* JDK 8.
I'd also add: do you also expect to run the unit and integration tests with JDK 
8?
could running be decoupled from compiling?

> > 
> > And when would that be needed?
I'd say it's a question of taste/aversion to risk: I personally fully trust JDK 
17 --release 8 to not produce anything wrong against JDK 8, but some may not 
trust
That's why I personally would accept building with JDK 17 --release 8 but would 
like to run UT/ITs with JDK 8

> 
> Isn't that needed for reproducible builds?

simply no

one concrete example from so many, just picking a random one: plexus-utils, 
that targets Java 8 bytecode 
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/codehaus/plexus/plexus-utils/README.md

as you can see, some releases were done with JDK 11, some with JDK 17, some on 
*nix and others on Windows
Each is reproducible, even if the required environment to get the same binaries 
as the reference published to Maven Central for each is different

while at it, I'll add:
this does not mean that for each release, any environment different from the 
reference one gives a bad output;
it just gives a different binary that is expected to be functionnally 
equivalent = what we blindly trusted before we checked binaries



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

working on plugins system requirements history: volunteers?

[Hervé Boutemy]

as discussed on the "Java version for Maven" thread(s), enablers are key IMHO

on plugins system requirements history, we started with
https://issues.apache.org/jira/browse/MPLUGIN-400

we need to fill data on every Maven -project plugin:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

some tooling creation may be useful:
https://issues.apache.org/jira/browse/MPLUGIN-511

and even the configuration solution needs a small improvement:
https://issues.apache.org/jira/browse/MPLUGIN-510


There is a lot of work to do for a single contributor, but that can be split in 
small tasks, with good first issues to contribute to
and it even has to be done in the future on every Maven plugin done in the wild

Are there volunteers? We can do meeting on this, coordination, progress 
publications, team work, on something that remain quite focused and not very 
complex

Regards,

Hervé



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

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler and 
tests: perhaps we'll need to open a separate discussion to avoid hijacking the 
global plan, but let's have one roundtrip

scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit and 
integration tests
of course, i have both JDKs on my machine

I see how I can manually configure toolchain.xml, modify pom.xml etc... to do 
that: it works, it's cumbersome

How does "dropping toolchains" help?

Defining a common plan will probably require a dedicated discussion, perhaps 
some wiki pages, perhaps some meeting between people interested to have more 
live ideation before sharing proposal on the ML (which is necessary for wider 
community discussion)

Le mercredi 21 février 2024, 08:48:43 CET Romain Manni-Bucau a écrit :
> Hi Hervé,
> 
> +1000 on the philosophy!
> 
> On the toolchain support I still fail to see why maven has toolchain
> anywhere in its code.
> Look it how it is used:
> * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> JAVAEA_HOME or alike)
> * Most plugins able to switch the JDK can switch the executable in their
> config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> is the same indirection than toolchain but without the downside to setup a
> toolchain.xml. Then plugins can just use the binary (optionally PathExt on
> windows to get the extension) and be it, works really well.
> 
> So overall I think we could drop toolchain which ultimately still misses a
> few parts to be complete in terms of env setup and make a shared-executable
> stronger - likely the future base of exec plugin even if not required.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
> Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
> 
> écrit :
> > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> > to update our plans
> > https://maven.apache.org/developers/compatibility-plan.html
> > 
> > the approach I'd love to promote is "what do we require to not hurt our
> > diversity of users when upgrading minimum prerequisites" (and I'm doing it
> > on my free time because I do care about the diversity of our community)
> > => let's work on the enablers
> > 
> > Java prerequisite for Maven core is something, but everything will start
> > from plugins: that's why we started the plugins "requirement history"
> > see for example
> > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> > 
> > for a summary on our own plugins, see last column of
> > 
> > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > b/master/site/dist-tool-prerequisites.html
> > 
> > As you can see, not many plugins are not covered yet: who wants to work on
> > this?
> > 
> > 
> > Another good item cited is improving decoupling JDK of Maven from JDK to
> > compile and run tests.
> > IIRC, Guillaume prepared something about auto-importing available JDKs
> > from sdkman, which is a great idea: I don't know if this was closed done,
> > but I suppose other JDK switcher tools should be supported, I'm
> > particularly interested on knowing what Windows users need
> > One aspect that I know is not well done is that the MANIFEST in jar
> > describes JDK release from Maven core, not target: we should probably do
> > something
> > Another aspect is that toolchains support has to be enabled in pom.xml: it
> > would be useful for it to work from just CLI also.
> > 
> > I'm sure there are other features that would be useful on this: who wants
> > to work on this?
> > 
> > 
> > The 2 previous enablers look sufficient to me: any other enabler someone
> > thinks about?
> > 
> > And more importantly: who wants to work on it? plan, track progress,
> > document, explain?
> > we need community's help to prepare a smooth change: updating our plans
> > will be a consequence of this preparation
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > > Howdy,
> > > 
> > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > > majority of Maven users do not run Maven on the same Ja

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to 
update our plans https://maven.apache.org/developers/compatibility-plan.html

the approach I'd love to promote is "what do we require to not hurt our 
diversity of users when upgrading minimum prerequisites" (and I'm doing it on 
my free time because I do care about the diversity of our community)
=> let's work on the enablers

Java prerequisite for Maven core is something, but everything will start from 
plugins: that's why we started the plugins "requirement history"
see for example 
https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html

for a summary on our own plugins, see last column of
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

As you can see, not many plugins are not covered yet: who wants to work on this?


Another good item cited is improving decoupling JDK of Maven from JDK to 
compile and run tests.
IIRC, Guillaume prepared something about auto-importing available JDKs from 
sdkman, which is a great idea: I don't know if this was closed done, but I 
suppose other JDK switcher tools should be supported, I'm particularly 
interested on knowing what Windows users need
One aspect that I know is not well done is that the MANIFEST in jar describes 
JDK release from Maven core, not target: we should probably do something
Another aspect is that toolchains support has to be enabled in pom.xml: it 
would be useful for it to work from just CLI also.

I'm sure there are other features that would be useful on this: who wants to 
work on this?


The 2 previous enablers look sufficient to me: any other enabler someone thinks 
about?

And more importantly: who wants to work on it? plan, track progress, document, 
explain?
we need community's help to prepare a smooth change: updating our plans will be 
a consequence of this preparation

Regards,

Hervé

Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> Howdy,
> 
> I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> majority of Maven users do not run Maven on the same Java version they
> target with their build. We do not do that either.
> 
> Some snippets from Herve (who is the ONLY one doing reproducible checks,
> kudos for that) votes:
> 
> Sun, Feb 18, 2024, 9:38 AM
> [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> Reproducible Build ok: reference build done with JDK 11 on *nix
> 
> Wed, Jan 31, 2024, 5:06 AM
> [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Mon, Jan 8, 2024, 8:29 AM
> [VOTE] Release Maven Plugin Tools version 3.11.0
> Reproducible Builds ok: reference build done with JDK 8 on Windows with
> umask
> 
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
> 
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
> 
> 
> 
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
> 
> 
> 
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
> 
> 
> Thanks
> T





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Romain Manni-Bucau, zhongming hua, Guillaume Nodet, Tamás Cservenák, 
Benjamin Marwell, Sylwester Lachiewicz, Slawomir Jaranowski, Karl Heinz 
Marbaise, Olivier Lamy
-1: Elliotte Rusty Harold

PMC quorum reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.

And let's continue merging PRs and giving feedback as much as possible



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

Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Hervé Boutemy]

FYI I reviewed PRs and merged what I was confident with
I can't say if this one can be merged: I don't know the feature sufficiently

I understand the good intent of the feedback, even if I find -1 a little bit 
strong: I did what I could, believe in my good intent too doing that release

Regards,

Hervé

Le dimanche 18 février 2024, 15:14:37 CET Elliotte Rusty Harold a écrit :
> On Sun, Feb 18, 2024 at 8:43 AM Romain Manni-Bucau
> 
>  wrote:
> > Hi Eliotte,
> > 
> > Is the -1 only motivated by the fact there is a PR opened?
> 
> That there is an unaddressed PR that looks worthy of review and has
> been open for months without a reply. 13 others are open. One of them
> is not ready for review. I haven't looked at the other 12 since, IMHO,
> one unreviewed PR is sufficient reason to delay a cut.
> 
> > If so please consider two things:
> > *  it is always the case for most releases (maven, asf, living projects
> > ;))
> > so not sure when it became a hard criteria but if so we should probably
> > think to be more open if we want to release a day
> 
> It isn't necessary to finish and merge all PRs before a release, but a
> review is not much to ask when someone has volunteered effort to fix
> something. Rarely, there's an emergency push for a critical bug. Short
> of that, it doesn't take all that long to scan the Github queue and
> see if there's anything useful that got missed. In practice though I
> often find even simple dependabot PRs unmerged after a release is cut.
> I would like to get in the habit of tidying up the queue prior to a
> release cut.
> 
> > * If you take time to review the PR you mention you will also see it just
> > revert a fix and that the final code should be more complex if it lands in
> > shade plugin a day - there are always workarounds there - so don't think
> > we
> > can make it in the week so can await another round and way more time to
> > make it right (long story sort shade has an old bug where it mixes the
> > same
> > config for different kind of rewritten sources, while it often works and
> > stays simple, it also makes it insanely hard to be right since you don't
> > know what you rewrite - a variable, a package, a class name, ...)
> 
> That's all fine, but please say this on the PR so the new contributor
> can address these points. It's not good for PRs to sit in limbo for
> years. Commenting on PRs also helps to avoid someone else who doesn't
> have the context you do (e.g. me) from coming along and simply merging
> the PR because I don't happen to notice the problems you do.





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

Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Hervé Boutemy]

+1

Reproducible Build ok: reference build done with JDK 11 on *nix

see 
https://github.com/jvm-repo-rebuild/reproducible-apache/blob/master/wip/maven-shade-plugin-3.5.2.buildspec

anybody should be able to rebuild locally with
  ./rebuild.sh wip/maven-shade-plugin-3.5.2.buildspec

Regards,

Hervé

Le samedi 17 février 2024, 19:00:47 CET Hervé Boutemy a écrit :
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921
> rsion=12352505=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2065/
> https://repository.apache.org/content/repositories/maven-2065/org/apache/mav
> en/plugins/maven-shade-plugin/3.5.2/maven-shade-plugin-3.5.2-source-release.
> zip
> 
> Source release checksum(s):
> maven-shade-plugin-3.5.2-source-release.zip sha512:
> 23fcd21e6b915114efa133b1c4e46fa0b3d77874ff9d974e4bdb24940ea0ed9b7ffaf7f3d1e
> 8a8549837cfe1de7ff2fc8ae7fc68bfc0477ea7a4b8b53e42f6f7%
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

[VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Hervé Boutemy]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352505=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-2065/
https://repository.apache.org/content/repositories/maven-2065/org/apache/maven/plugins/maven-shade-plugin/3.5.2/maven-shade-plugin-3.5.2-source-release.zip

Source release checksum(s):
maven-shade-plugin-3.5.2-source-release.zip sha512: 
23fcd21e6b915114efa133b1c4e46fa0b3d77874ff9d974e4bdb24940ea0ed9b7ffaf7f3d1e8a8549837cfe1de7ff2fc8ae7fc68bfc0477ea7a4b8b53e42f6f7%

Staging site:
https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1




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

Re: Java version for Maven 4?

[Hervé Boutemy]

Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet a écrit :
> At build time, I think it's fine to bump to whatever is needed to make
> our life manageable. If 17 is required, so be it.
+1

my biggest concern with Maven 4 is not JDK runtime requirement, but plugins 
future when a plugin wants to be able to use the new Maven 4 API

IIUC, Maven 4 has a compatibility layer to run Maven Plugin 3.x (= built with 
Maven 3 plugin API).
On our core plugins, there is a Maven 4 branch that tests what the plugin 
would become when it migrates to new Maven 4 API (and check that Maven 4 API 
works as expected)

But IIUC, once a plugin uses Maven 4 API, it de-facto cannot be run on Maven 3

Questions:
- is that true at plugin level or goal level?
- new Maven 4 API for now is not so much about providing new features, but 
improving/clarifying plugin  expectations from Maven core: are there known 
features in Maven 4 API not available in Maven 3 that would bring stronger 
interest in writing a goal for Maven 4?

concern: does it mean that we either should not upgrade our master branches to 
Maven 4 API too early? Will we need to maintain a 3.x branch in parallel to 4/
main branch?
And the questions I have for plugins maintained at Maven project level will 
impact every third party plugin maintainer: we need to make things explicit, 
IMHO
The JVM upgrade in parallel IMHO is less a concern, as it is a consequence of 
previous plugin prerequisite choice on Maven

Hervé

> 
> Guillaume
> 
> Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
> 
>  a écrit :
> > Hello
> > 
> > I would like a little clarification about the Java version for Maven 4.
> > I saw debate on this mailing list, but has a decision been reached? I
> > got the impression that Maven 4 would require Java 11, but last time I
> > checked, the pom.xml file was still declaring Java 8 as the target. If
> > Java 11 is the target, updating the pom.xml would unlock some features
> > and make some code a little bit simpler.
> > 
> > Related question: even if Maven 4 targets Java 8 or 11, would it be
> > acceptable to require Java 17 with `--release 8` or `--release 11`
> > option only for Maven 4 compilation (not execution)? I ask because as
> > far as I know, we cannot write code buildable with both Java 11 and Java
> > 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> > checks are enabled. If the project builds on Java 11, then it fails on
> > Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> > building on both versions, we must either avoid HTML headings, or
> > disable Javadoc checks (more details at [1]). Using HTML headings is not
> > very important, so they could be removed. But the `--release 11`
> > approach would allow a more gradual transition to newest Java versions
> > while preserving compatibility for users.
> > 
> >  Martin
> > 
> > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221





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

Re: [VOTE] Release Maven Doxia version 2.0.0-M9

[Hervé Boutemy]

uh, it had been dropped by inadvertance in 
https://github.com/apache/maven-doxia-site/commit/ecd62ed94b6e9445237e780171edff8f437a4895

doxia-tools needs rework, since it's not only one component but a collection, 
like plugins/ in Maven site

I'll do the update

Le dimanche 7 janvier 2024, 12:47:07 CET Michael Osipov a écrit :
> Am 2024-01-07 um 11:30 schrieb Konrad Windszus:
> > +1
> > 
> > The mentioned staging site
> > https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/ is not
> > working though (returns a 404), but the HTML source in
> > https://svn.apache.org/repos/asf/maven/doxia/website/components/doxia-arc
> > hives/doxia-LATEST/index.html looks ok to me (svnpubsub set up correctly
> > here?)
> Beat me, but I don't get it. This was missing:
> https://github.com/apache/maven-doxia-site/commit/1968569cd11a856a920112cb85
> b0f032d08f7fc1 but why did it work the years before? I am really confused...
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Nexus returns 400 Bad Request

[Hervé Boutemy]

interesting details

IMHO, we're back to the HTTP wire protocol between Maven CLI and repositories 
not being precisely defined on edge cases
= what to put as HTTP return code, what to put as reason phrase (deprecated in 
HTTP/1.1, removed in HTTP/2), and what to get from HTTP body

idea has been shared some time ago about using RFC 7807, but nothing has been 
really done
see https://issues.apache.org/jira/browse/MNG-6795 , marked as candidate for 
Maven 4, but did not get much traction for now

Regards,

Hervé

Le vendredi 5 janvier 2024, 19:11:57 CET Romain Manni-Bucau a écrit :
> Hi,
> 
> This is a valid error but if you want to see it you need to enable HTTP
> frames.
> 
> For the record the error returns a HTML response with this content:
> *Cannot find a matching staging profile*.
> 
> If you want to check them out it depends a bit of your maven version but
> for 3.9 you just comment the two last lines
> of $MAVEN_HOME/conf/logging/simplelogger.properties
> (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for
> maven 4 you can use the JVM httpclient system properties IIRC).
> 
> But agree our client could be more precise on the error instead of just
> throwing a 400 without any message, if you feel motivated to send a pr it
> would be welcomed I guess.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> Le ven. 5 janv. 2024 à 18:46, Michael Osipov  a écrit :
> > On 2024/01/04 14:00:08 tison wrote:
> > > Hi,
> > > 
> > > When deploying artifacts to Nexus repository, 400 Bad Request can be
> > > one of the most confusing error code. See [1] as an example.
> > > 
> > > Sonatype has a page to document some common causes of 400 Bad Request
> > > [2]. But I wonder if we can return an error message (diagnostic) along
> > > with the error code, so that users can get what conditions broken
> > > exactly.
> > > 
> > > I suppose it has been discussed before. Is there any reference about
> > > this? What is the related components / code I can check for potential
> > > contributions (fixes)?
> > > 
> > > Best,
> > > tison.
> > > 
> > > [1] https://issues.apache.org/jira/browse/INFRA-25344
> > > [2] https://central.sonatype.org/faq/400-error/
> > 
> > Looking at the INFRA issue it seems that 400 is just wrong. There is not
> > client issue here, but a permission issue which should give you 403. Maybe
> > that is a bug in Nexus itself.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Hervé Boutemy]

for the records, "Maven Plugins Compatibility Plan" strategy is stored in
 https://maven.apache.org/developers/compatibility-plan.html

= the doc to refer to and update if necessary after the current discussion

Le vendredi 29 décembre 2023, 14:42:17 CET Slawomir Jaranowski a écrit :
> Hi,
> 
> Last year we mark all Maven versions 3.6.x and older as EOL [1]
> 
> But we still try to support minimal API version for Core Maven Plugins as
> 3.2.5
> 
> I would like to  propose to sich it for at least to 3.6.3
> 
> Reasonable reasons: (for me)
>  - for standard CI build we use Maven 3.6.3 and newer
>  - many of external plugins, like MojoHaus are switched to 3.6.3
>  - we have a hacks in code to try support old version in plugin, like
> in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can cleanup
> such code
> - I don't believe to someone want to do more fixes for EOL Maven version in
> plugins - so we should be a honest for users
> - and we should go forward
> 
> [1] https://maven.apache.org/docs/history.html
> [2]
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report
> -plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPlu
> ginDescriptorBuilder.java





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

Re: Plugins documentations - improvements

[Hervé Boutemy]

notice that it is also the javadoc spirit: when there is a long multi-line 
description, table is expected to keep only first line and detail the full 
description

Le samedi 23 décembre 2023, 23:29:22 CET Konrad Windszus a écrit :
> Hi,
> currently those sections deviate slightly (e.g. the overview does not
> evaluate deprecation info) but we can probably consolidate overview and
> details into one section. Look at
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-repor
> t-plugin/src/main/java/org/apache/maven/plugin/plugin/report/GoalRenderer.ja
> va for details. If you propose something in a PR I will happily review.
> Probably at the same time we should get rid of required vs optional as
> required often comes with a default value… Konrad
> 
> > On 23. Dec 2023, at 22:00, Michael Osipov  wrote:
> > 
> > Am 2023-12-23 um 12:42 schrieb Slawomir Jaranowski:
> >> Hi,
> >> We have generated plugins documentations by Maven Plugin Report Plugin
> >> In generated documentation by gola we have:
> >> - introduction sections describe plugin goal
> >> - required and optional parameters sections - which describe parameters
> >> in
> >> table
> >> We also have "Parameter Details" sections which contain exactly the same
> >> information that we have in tables with parameter descriptions.
> > 
> > First of all, good catch, duplicate information is bad information because
> > it confuses the reader..> 
> >> Questions:
> >>  - Do we need duplicated information on the same page?
> > 
> > No we don't. It does only add clutter and not benefit.
> > 
> >>  - What do you think about removing the "Parameter Details" section?
> > 
> > I think that would be wrong. It should be the other way around. My
> > understanding:
> > 
> > = Goal or Mojo {name}
> > Full name: ...
> > Description: ...
> > Attributes:
> > ^^
> > I don't see any attributes listed here at all. It is rather enviromental
> > characteristics/conditions/etc. == Parameter Overview
> > === Required Parameters
> > Name, Type, Since, Description
> > 
> >^  ^^^
> > 
> > * Since: Why is this a column while in goal/mojo it is a bullet point, I
> > mean it could also be in description. * Description: Should only contains
> > characterics: default, property, etc. The column should not be called
> > 'Description at all. May the characteristics should be column for their
> > own, like name, type, etc.?
> > 
> > === Optional Parameters
> > Like required
> > 
> > == Parameter Details
> > === {element name}
> > {Description}
> > Characteristics should maybe contain a label, e.g.,
> > 
> > Characteristics:
> > * Type: ...
> > * Since: ...
> > * and so on
> > 
> > M
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Plugins documentations - improvements

[Hervé Boutemy]

in early days, from memory, there were a few fields displayed only in the 
details section
https://maven.apache.org/plugins-archives/maven-compiler-plugin-2.2/compile-mojo.html
like expression: I don't find anything else (perhaps even older reports had 
more fields like this one)

but you're right, this has been updated for a long time: now it seems it's 
full (generated) redundancy

the only detail to keep is the anchor: I imagine it can be moved from details 
section to the table

Regards,

Hervé

Le samedi 23 décembre 2023, 12:42:07 CET Slawomir Jaranowski a écrit :
> Hi,
> 
> We have generated plugins documentations by Maven Plugin Report Plugin
> 
> In generated documentation by gola we have:
> 
> - introduction sections describe plugin goal
> 
> - required and optional parameters sections - which describe parameters in
> table
> 
> We also have "Parameter Details" sections which contain exactly the same
> information that we have in tables with parameter descriptions.
> 
> Questions:
>  - Do we need duplicated information on the same page?
>  - What do you think about removing the "Parameter Details" section?
> 
> Example:
> https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html





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

Re: Maven profiles and dependency resolution

[Hervé Boutemy]

Hi Piotr,

Thinking at it carefully, AFAIK it is a design decision done in early Maven 2 
design time:
- POM properties don't influence dependencies
- profile activation influence dependencies
(I don't know for CLI properties)

The rationale is that:

1. POM properties are expected to be fixed once a release is done and designed 
as internal details: injecting from one project to its dependencies would 
create quite complex to detect collisions.

2. profiles have been thought as a way to define multiple variants of a 
project, 
with a limited number of supported value on each project: having dependencies 
influenced by profile (defined on CLI) makes sense

HTH

Hervé

Le vendredi 15 décembre 2023, 09:34:27 CET Piotr P. Karwasz a écrit :
> Hello,
> 
> While looking at differences in generated CycloneDX SBOMs[1] I
> stumbled upon an incoherence in the way Maven builds models of a
> project's dependencies.
> 
> On one hand the properties defined in a project have no effect on the
> effective models of dependencies. For example in:
> 
> 
>   3.0.0-beta1
> 
> 
>   
> 
>   org.springframework
>   spring-boot-dependencies
>   3.2.0
>   pom
>   import
> 
>   
> 
> 
> the `log4j2.version` property will have no effect on the resolved
> effective model of `spring-boot-dependencies`, even if the POM also
> uses a `log4j2.version` variable[2].
> 
> On the other hand profiles change the effective model of a dependency.
> E.g. using:
> 
> 
>   
> commons-pool
> commons-pool
> 1.5.4
>   
> 
> 
> the effective model of `commons-pool` will have a different
> `` element if I run the project with
> `-Prelease` or without it.
> 
> Is this an intentional choice or is it a bug? I suppose that profiles
> might influence the other artifacts in a Maven reactor, but I am not
> sure external dependencies should be influenced as well.
> 
> Piotr
> 
> [1] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/432
> [2]
> https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-depende
> ncies/3.2.0/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: injecting an object for plugin configuration on Maven CLI

[Hervé Boutemy]

thank you Konrad
I feared that
IIUC, I'll have to add a parameter for CLI use that will parse a specific 
format: I'll try and share, so we can evaluate options

Regards,

Hervé

Le vendredi 17 novembre 2023, 10:55:55 CET Konrad Windszus a écrit :
> Hi,
> Only the value classes listed in
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping
> _Value_Objects support conversion from string. There is nothing built in for
> complex classes containing multiple values of different types.
> 
> Konrad
> 
> > On 17. Nov 2023, at 08:51, Hervé Boutemy  wrote:
> > 
> > my use case: I want sometimes to execute maven-toolchain-plugin or animal-
> > sniffer-maven-plugin on CLI without updating pom.xml
> > 
> > the only issue I'm facing is how to write the -D properties to populate a
> > few fields from Objects required in plugin configuration:
> > 
> > - signature groupId/artifactId/version for Animal Sniffer equivalent to
> > pom.xml's configuration
> > https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/usage.
> > html
> > 
> > - even simpler for toolchain: just one toolchains.jdk.version value like
> > https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/
> > jdk.html#sample-plugin-configuration
> > 
> > Is there some Sisu magic for that, or do we need to add a specific extra-
> > handling of this use case at goal level?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

injecting an object for plugin configuration on Maven CLI

[Hervé Boutemy]

my use case: I want sometimes to execute maven-toolchain-plugin or animal-
sniffer-maven-plugin on CLI without updating pom.xml

the only issue I'm facing is how to write the -D properties to populate a few 
fields from Objects required in plugin configuration:

- signature groupId/artifactId/version for Animal Sniffer equivalent to 
pom.xml's configuration
 https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/usage.html

- even simpler for toolchain: just one toolchains.jdk.version value like 
https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/
jdk.html#sample-plugin-configuration

Is there some Sisu magic for that, or do we need to add a specific extra-
handling of this use case at goal level?

Regards,

Hervé



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

Re: Changing Minimum Build Requirements for plugins to JDK11

[Hervé Boutemy]

no need to change the build prerequisite: just add a profile to activate the 
release flag on newer JDK:
https://issues.apache.org/jira/browse/MPOM-447

Regards,

Hervé

Le lundi 13 novembre 2023, 20:38:00 CET Karl Heinz Marbaise a écrit :
> Hi,
> 
> currently we have already the build requirements for Maven Core at JDK11+
> 
> So in consequence I would suggest to lift the minimum requirement for
> building plugins to JDK11.
> 
> That means also we can use "--release 8" option
> (8) instead of
> source/target which is not correct based on the warnings we get like:
> "[WARNING] bootstrap class path not set in conjunction with -source 8"
> which we get in all plugins based on the configuration in maven parent
> using this:
> 
>  8
>  1.${javaVersion}
>  1.${javaVersion}
> 
> which is not correct because we don't use animalsniffer anymore.
> 
> So my suggestion is to lift the JDK build requirements to JDK11...
> and use the 8 which
> will prevent the warning. Also brings us back the safety net which
> animal-sniffer was before.
> 
> 
> Later on version of maven-parent (v42?) should change the whole
> configuration (there are some related parts like maven-pmd-plugin,
> maven-enforcer-plugin (enforce-byte-code max)..also toolchain-plugin...
> 
> Furthermore we could get rid of the profile for JDK11+ related to
> spotless-maven-plugin ...
> 
> Based on the upgrade to maven-parent v41 we could also enhance the build
> pipelines to build on JDK21
> 
> WDYT?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Apache Maven 4.0.0-alpha-8 release

[Hervé Boutemy]

Le lundi 23 octobre 2023, 10:00:59 CEST Guillaume Nodet a écrit :
> Le sam. 21 oct. 2023 à 18:19, Herve Boutemy  a écrit :
> > I updated release notes
> > 
> > a few remarks/questions:
> > 
> > - it would be nice to have a description in Jira issues for all the new
> > features, because some titles are interesting but Jira is empty and I
> > can't
> > figure out how to use the feature (alternative pom syntax, model version
> > analysis and downgrade, glob patterns in dependency exclusions)
> 
> Sounds good, I'll try to add some.
thank you

> 
> > - is model 4.1.0 documentation generated somewhere?
> 
> Which documentation ?  I think we should prepare for when we'll release
> 4.0.0 GA, but I would consider 4.1.0 as a moving target until that time.
here is 4.0.0 reference documentation
 https://maven.apache.org/ref/3.9.5/maven-model/maven.html

i expect to have an equivalent for 4.1.0


> 
> > - given Plexus XML was removed in favor or StAX, is plexus-xml 4 still
> > something useful?
> 
> Plexus-utils has been removed as a core dependency, but it's still a
> dependency of Sisu.
> For plexus-xml, even if the parser used is now mostly Stax, there are still
> a couple of references to the xpp3 one in XmlNodeBuilder and in
> maven-compat.
> For compatibility with all plugins, I don't think we'll be able to remove
> it in the near future.
ok, I see, thanks

> 
> > - I suppose I'll have to add BOM packaging documentation to
> > https://maven.apache.org/ref/4-LATEST/maven-core/default-bindings.html

it would be nice to have reference documentation
 https://maven.apache.org/ref/4-LATEST 
following code updates: documentation is not only when the final release 
happens

> > 
> > On 2023/10/21 14:34:32 Herve Boutemy wrote:
> > > +1
> > > 
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > 
> > umask 022 and Maven 4.0.0-alpha-8 itself (yes...)
> > 
> > > a few remarks:
> > > - I'll add some updates to release notes later
> > > - during tests, I found that an active repository configured in my
> > 
> > settings.xml had been added to the published consumer POM: I'm wondering
> > if
> > such behaviour is not a risk of leak of personal data
> > 
> > > - the fact that the site is borked, then maven-site-plugin seems not to
> > 
> > be fully working with this release shows that changes broke some things:
> > not a blocker, it's an alpha, but definitively we need people testing
> > their
> > own projects and reporting when they find such issues
> > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > On 2023/10/20 21:37:10 Guillaume Nodet wrote:
> > > > I'm starting a new vote to release this new alpha.
> > > > 
> > > > This alpha release provides new cornerstone features for the future
> > 
> > Maven
> > 
> > > > evolution.
> > > > In particular, the POM model which was set in stone to a 4.0.0 version
> > > > since Maven 3.0, is now able to evolve. For modules that have a
> > 
> > packaging
> > 
> > > > which is not POM, the flattened consumer POM is now installed/deployed
> > > > instead of the main POM, eventually translated back into a 4.0.0 model
> > > > version for consumer compatibility. The build POM is also installed /
> > > > deployed unchanged. This allows the introduction of the 4.1.0 model
> > 
> > which
> > 
> > > > already brings a few improvements.
> > 
> > > > 50 issues solved:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922;
> > version=12353356> 
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/maven-2011
> > > > 
> > > > Dev dist directory:
> > > > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-8/
> > > > 
> > > > Source release checksums:
> > 
> > > > apache-maven-4.0.0-alpha-8-src.zip sha512:
> > 7264b5ae1a567ff9249f8020bc5713386f26bdd297b499e309a70897d03b647ef5a1446d10
> > 963529fd50dbab0ee56f5357ab39405462b8a5326a99bae80222c9> 
> > > > apache-maven-4.0.0-alpha-8-src.tar.gz sha512:
> > d645e4015119836428e16bd5d4dd29bed6d4983d552445cdf587a61f0a2347a619e9de02cd
> > c590eda000c4561e60e33e758aa83dca3d6243ede97f5be981b322> 
> > > > Binary release checksums:
> > 
> > > > apache-maven-4.0.0-alpha-8-bin.zip sha512:
> > 6aa9486e2d880b691580e0071347022b6426f0a6b2c6549879b6a848a4494c70ff8dff25ff
> > e8de2edd82583d7119bf359156ece0f9ef18f1c99ff3db776461f3> 
> > > > apache-maven-4.0.0-alpha-8-bin.tar.gz sha512:
> > 7646b5bbaa0b81e600076055134ba88d5bd02d7a0ae03829b7e217aad9e47c25a3edbf4b09
> > 1562d4bc9d93b5a50e84449a679f18052dc4f97d0314a8bc9dd961> 
> > > > Staged site:
> > > > https://maven.apache.org/ref/4-LATEST/
> > > > 
> > > > Draft for release notes:
> > > > https://github.com/apache/maven-site/pull/462
> > 
> > https://github.com/apache/maven-site/blob/21deeaf4a0fc4993e0091d214f194195
> > dc66c167/content/markdown/docs/4.0.0-alpha-8/release-notes.md> 
> > > > Guide to testing staged releases:
> > > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > > > 
> > > > Note that this 

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M10

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 8 on Windows and umask 
022

Regards,

Hervé

Le mardi 3 octobre 2023, 11:12:36 CEST Michael Osipov a écrit :
> Hi,
> 
> IMPORTANT: Requires Doxia Sitetools 2.0.0-M12, Maven Reporting Impl
> 4.0.0-M10, Maven Reporting Exec 2.0.0-M10 vote/staging repo!
> 
> we solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923
> rsion=12353491
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20res
> olution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1998/
> https://repository.apache.org/content/repositories/maven-1998/org/apache/mav
> en/plugins/maven-site-plugin/4.0.0-M10/maven-site-plugin-4.0.0-M10-source-re
> lease.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M10-source-release.zip
> sha512:
> 48441222e9d8cc310592e6cab56224dc87d442c9a7ba77c48d6659dbf02799c83e0d8481f146
> 6a039ce44ed6795283960e7b5341e8270785f3a488b00bc9ccdb
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Apache Maven Reporting Exec version 2.0.0-M10

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 8 on Windows and umask 
022

Regards,

Hervé

Le mardi 3 octobre 2023, 00:14:52 CEST Michael Osipov a écrit :
> Hi,
> 
> IMPORTANT: Requires Doxia Sitetools 2.0.0-M12, Maven Reporting Impl
> 4.0.0-M10 vote/staging repo!
> 
> we solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12353680
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20r
> esolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-exec
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1997/
> https://repository.apache.org/content/repositories/maven-1997/org/apache/mav
> en/reporting/maven-reporting-exec/2.0.0-M10/maven-reporting-exec-2.0.0-M10-s
> ource-release.zip
> 
> Source release checksum(s):
> maven-reporting-exec-2.0.0-M10-source-release.zip
> sha512:
> c8ec8bdd9696656d5d1f66b2abc3f6d25c52b14df234c87f23fddd13dbd29cf4d93b23e5ab97
> 47e85b75f9eef03da0ee714bfd9ffb80254f13e05004ae5f46bc
> 
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-exec-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Apache Maven 3.9.5

[Hervé Boutemy]

I updated my svn and ran:

for f in *
do
  rm $f
  wget 
https://repository.apache.org/content/repositories/maven-1996/org/apache/maven/apache-maven/3.9.5/$f
 
done

both in source and binaries: this resulted in .asc change in source only, 
everything else was ok

I committed the update

now we have:
❯ svn log

r64327 | hboutemy | 2023-10-03 23:37:28 +0200 (Tue, 03 Oct 2023) | 1 line

update signature with new staging content

r64300 | cstamas | 2023-10-02 20:06:52 +0200 (Mon, 02 Oct 2023) | 2 lines

Updated Maven 3.9.5 bin bundles


r64283 | cstamas | 2023-10-01 20:44:52 +0200 (Sun, 01 Oct 2023) | 3 lines

Apache Maven 3.9.5

Regards,

Hervé

Le mardi 3 octobre 2023, 23:23:06 CEST Tamás Cservenák a écrit :
> Karl,
> 
> Are you sure your SVN checkout is up to date?
> As I did change archives along with signatures and checksums, and they
> should be OK
> 
> This is the commit email of my change:
> https://lists.apache.org/thread/7wn1sgd7hbcndtgypvjz4qzx0d2brobx
> 
> Can someone else verify this?
> 
> Thanks
> T
> 
> On Tue, Oct 3, 2023 at 1:05 PM Karl Heinz Marbaise 
> 
> wrote:
> > Hi,
> > 
> > the permissions in the .tar.gz archive are Ok now.
> > 
> > Please update the SHA512 because it's the previous one..(I've checked
> > the .tar.gz) but I assume that the SHA512 for the -bin.zip has changed
> > also)...
> > 
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.5/binaries/
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > On 02.10.23 11:10, Tamás Cservenák wrote:
> > > Bah,
> > > 
> > > This is the same problem as before... but originally it happened on my
> > > desktop. This time the release was done from my laptop :(
> > > 
> > > I believe the fix is the same as before: I should rebuild from the tag,
> > > after I fixed my local repository, as source bundles we vote on are
> > > unchanged...
> > > 
> > > T
> > > 
> > > 
> > > On Mon, Oct 2, 2023 at 9:14 AM Herve Boutemy 
> > 
> > wrote:
> > >> thinking twice, I need to change to -1: this may impact users that
> > 
> > expect
> > 
> > >> to use the group permissions to use Maven binaries
> > >> 
> > >> sorry
> > >> I don't know what tests you are doing with permissions on your
> > >> environment, but these tests leak releases :(
> > >> 
> > >> Regards,
> > >> 
> > >> Hervé
> > >> 
> > >> On 2023/10/02 07:11:02 Herve Boutemy wrote:
> > >>> +1
> > >>> 
> > >>> but Reproducible not fully ok: reference build done with JDK 17 on
> > >>> *nix
> > >> 
> > >> and umask 022
> > >> 
> > >>> apache-maven-3.9.5-bin.zip and .tar.gz suffer from weird umask (go-r)
> > 
> > on
> > 
> > >> wagon jars:
> > >>> $ diffoscope
> > >> 
> > >> target/reference/org.apache.maven/apache-maven-3.9.5-bin.zip
> > >> apache-maven/target/apache-maven-3.9.5-bin.zip
> > >> 
> > >>> --- target/reference/org.apache.maven/apache-maven-3.9.5-bin.zip
> > >>> +++ apache-maven/target/apache-maven-3.9.5-bin.zip
> > >>> │┄ Archive contents identical but files differ, possibly due to
> > >> 
> > >> different compression levels. Falling back to binary comparison.
> > >> 
> > >>> ├── zipinfo {}
> > >>> │ @@ -81,21 +81,21 @@
> > >>> │  -rw-r--r--  2.0 unx74345 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/maven-resolver-provider-3.9.5.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx   317619 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/maven-resolver-impl-1.9.16.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx37757 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/maven-resolver-named-locks-1.9.16.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx51503 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/maven-resolver-spi-1.9.16.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx   379348 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/org.eclipse.sisu.inject-0.3.5.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx 4225 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/plexus-component-annotations-2.1.0.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx   289577 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/maven-compat-3.9.5.jar
> > >> 
> > >>> │ --rw---  2.0 unx55101 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/wagon-provider-api-3.5.3.jar
> > >> 
> > >>> │ +-rw-r--r--  2.0 unx55101 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/wagon-provider-api-3.5.3.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx   205307 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/org.eclipse.sisu.plexus-0.3.5.jar
> > >> 
> > >>> │  -rw-r--r--  2.0 unx58284 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/commons-cli-1.5.0.jar
> > >> 
> > >>> │ --rw---  2.0 unx 9405 b- defN 23-Oct-01 18:38
> > >> 
> > >> apache-maven-3.9.5/lib/wagon-http-3.5.3.jar
> > 

Re: [VOTE] Release Apache Maven 3.9.5

[Hervé Boutemy]

yes, you can drop the staging repository and re-deploy: only the 2 -bin 
archives will be different

Regards

Hervé

Le lundi 2 octobre 2023, 11:10:36 CEST Tamás Cservenák a écrit :
> Bah,
> 
> This is the same problem as before... but originally it happened on my
> desktop. This time the release was done from my laptop :(
> 
> I believe the fix is the same as before: I should rebuild from the tag,
> after I fixed my local repository, as source bundles we vote on are
> unchanged...
> 
> T
> 
> On Mon, Oct 2, 2023 at 9:14 AM Herve Boutemy  wrote:
> > thinking twice, I need to change to -1: this may impact users that expect
> > to use the group permissions to use Maven binaries
> > 
> > sorry
> > I don't know what tests you are doing with permissions on your
> > environment, but these tests leak releases :(
> > 
> > Regards,
> > 
> > Hervé
> > 
> > On 2023/10/02 07:11:02 Herve Boutemy wrote:
> > > +1
> > > 
> > > but Reproducible not fully ok: reference build done with JDK 17 on *nix
> > 
> > and umask 022
> > 
> > > apache-maven-3.9.5-bin.zip and .tar.gz suffer from weird umask (go-r) on
> > 
> > wagon jars:
> > > $ diffoscope
> > 
> > target/reference/org.apache.maven/apache-maven-3.9.5-bin.zip
> > apache-maven/target/apache-maven-3.9.5-bin.zip
> > 
> > > --- target/reference/org.apache.maven/apache-maven-3.9.5-bin.zip
> > > +++ apache-maven/target/apache-maven-3.9.5-bin.zip
> > > │┄ Archive contents identical but files differ, possibly due to
> > 
> > different compression levels. Falling back to binary comparison.
> > 
> > > ├── zipinfo {}
> > > │ @@ -81,21 +81,21 @@
> > > │  -rw-r--r--  2.0 unx74345 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-provider-3.9.5.jar
> > 
> > > │  -rw-r--r--  2.0 unx   317619 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-impl-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx37757 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-named-locks-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx51503 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-spi-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx   379348 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/org.eclipse.sisu.inject-0.3.5.jar
> > 
> > > │  -rw-r--r--  2.0 unx 4225 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/plexus-component-annotations-2.1.0.jar
> > 
> > > │  -rw-r--r--  2.0 unx   289577 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-compat-3.9.5.jar
> > 
> > > │ --rw---  2.0 unx55101 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-provider-api-3.5.3.jar
> > 
> > > │ +-rw-r--r--  2.0 unx55101 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-provider-api-3.5.3.jar
> > 
> > > │  -rw-r--r--  2.0 unx   205307 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/org.eclipse.sisu.plexus-0.3.5.jar
> > 
> > > │  -rw-r--r--  2.0 unx58284 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/commons-cli-1.5.0.jar
> > 
> > > │ --rw---  2.0 unx 9405 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-http-3.5.3.jar
> > 
> > > │ --rw---  2.0 unx40832 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-http-shared-3.5.3.jar
> > 
> > > │ --rw---  2.0 unx   785639 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/httpclient-4.5.14.jar
> > 
> > > │ --rw---  2.0 unx11350 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-file-3.5.3.jar
> > 
> > > │ +-rw-r--r--  2.0 unx 9405 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-http-3.5.3.jar
> > 
> > > │ +-rw-r--r--  2.0 unx40832 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-http-shared-3.5.3.jar
> > 
> > > │ +-rw-r--r--  2.0 unx   785639 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/httpclient-4.5.14.jar
> > 
> > > │ +-rw-r--r--  2.0 unx11350 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/wagon-file-3.5.3.jar
> > 
> > > │  -rw-r--r--  2.0 unx16555 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/jcl-over-slf4j-1.7.36.jar
> > 
> > > │  -rw-r--r--  2.0 unx40277 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-connector-basic-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx16249 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-transport-file-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx55689 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-transport-http-1.9.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx   327891 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/httpcore-4.4.16.jar
> > 
> > > │  -rw-r--r--  2.0 unx   360738 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/commons-codec-1.16.0.jar
> > 
> > > │  -rw-r--r--  2.0 unx32488 b- defN 23-Oct-01 18:38
> > 
> > apache-maven-3.9.5/lib/maven-resolver-transport-wagon-1.9.16.jar
> > 
> > > │   --- 

Re: [VOTE] Release Apache Maven Reporting Impl version 4.0.0-M10

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 8 on Windows and umask 
022

Regards,

Hervé

Le dimanche 1 octobre 2023, 20:19:26 CEST Michael Osipov a écrit :
> Hi,
> 
> IMPORTANT: Requires Doxia Sitetools 2.0.0-M12 vote/staging repo!
> 
> we solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12353492
> 
> There are no issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20r
> esolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1994/
> https://repository.apache.org/content/repositories/maven-1994/org/apache/mav
> en/reporting/maven-reporting-impl/4.0.0-M10/maven-reporting-impl-4.0.0-M10-s
> ource-release.zip
> 
> Source release checksum(s):
> maven-reporting-impl-4.0.0-M10-source-release.zip
> sha512:
> 1e51d44a8047dec49e9f2087a92dc86cb86413a78bc3a1f3324ba89e3f76c044c591ec5df688
> cc37b7535aa91ab532b32ecf990aae9bd0b9020b00e74847a417
> 
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-impl-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M12

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 8 on Windows and umask 
022

Regards,

Hervé

Le dimanche 1 octobre 2023, 20:03:02 CEST Michael Osipov a écrit :
> Hi,
> 
> we solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320
> rsion=12353413
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20
> status%20%3D%20Open
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1993
> https://repository.apache.org/content/repositories/maven-1993/org/apache/mav
> en/doxia/doxia-sitetools/2.0.0-M12/doxia-sitetools-2.0.0-M12-source-release.
> zip
> 
> Source release checksum(s):
> doxia-sitetools-2.0.0-M12-source-release.zip
> sha512:
> f78a743d75fd551a8fdc1e80050d2f2fdb68c3e43840524bb94cb9ab3a5c98f3322d143883e4
> 2f25dd61cb112425114ec0e39b4a18a87208cad3832f5af9
> 
> Staging site:
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATE
> ST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> IMPORTANT: This is expected to be the last milestone before 2.0.0 GA.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

[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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven Artifact Plugin version 3.5.0

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Sylwester Lachiewicz, Tamás Cservenák, Michael Osipov, Hervé Boutemy

PMC quorum reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.



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

Fwd: Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0

[Hervé Boutemy]

was intended to the list :)

--  Message transmis  --

Objet : Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0
Date : samedi 30 septembre 2023, 18:45:51 CEST
De : Michael Osipov 
À : Hervé Boutemy 

Am 2023-09-29 um 08:00 schrieb Hervé Boutemy:
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12324322=12353118=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1992/
> https://repository.apache.org/content/repositories/maven-1992/org/apache/
maven/plugins/maven-artifact-plugin/3.5.0/maven-artifact-plugin-3.5.0-source-
release.zip
> 
> Source release checksum(s):
> maven-artifact-plugin-3.5.0-source-release.zip sha512: 
3155f2e3da07752473fe5a2deb5b32f108c2fb1d8cd786718852f18242afad515fafcf55710f03c136fff9f343702e8e0152d53d51f69f6c043ecc397ce818e1%
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.

+1


-



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

Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done on *nix with JDK 11

Regards,

Hervé

Le vendredi 29 septembre 2023, 08:00:39 CEST Hervé Boutemy a écrit :
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322
> rsion=12353118=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1992/
> https://repository.apache.org/content/repositories/maven-1992/org/apache/mav
> en/plugins/maven-artifact-plugin/3.5.0/maven-artifact-plugin-3.5.0-source-re
> lease.zip
> 
> Source release checksum(s):
> maven-artifact-plugin-3.5.0-source-release.zip sha512:
> 3155f2e3da07752473fe5a2deb5b32f108c2fb1d8cd786718852f18242afad515fafcf55710
> f03c136fff9f343702e8e0152d53d51f69f6c043ecc397ce818e1%
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

verifying signatures, PGP or ... (was Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0)

[Hervé Boutemy]

very useful feedback

creating a separate thread because this will be a useful discussion, 
completely independent from the vote

I added PGP signatures verification to this project as an IRL test, to get real 
experience on the impact: yes, it makes dependencies upgrade harder because 
often, different releases of the same project don't use the same PGP key...

and you're right to ask a more fundamental question: is it useful to check at 
build time?
I'll add: is it useful to sign if nobody checks?

I don't have a definitive answer: I just know that currently a Maven build 
downloads many binaries, checks fingerprints that prove that there was no data 
loss against the origin server. But this does not prove that it has not been 
actively tampered by a bad actor.
Then I'm convinced that checking signatures can improve our security, if we 
find a stable way to define accepted keys for each project: perhaps the plugin 
should support downloading  KEYS files from Apache projects? What about other 
projects that don't provide such a KEYS file?

FYI, I'm working on sigstore signature, that is proven easier to use to sign: 
but on checking signature, everything remains to be defined. Who does signature 
checks. When? How? And it is only once we'll have some insights that we'll be 
able to see if checking experience is better or not.


Happy to get feedback from everybody

Regards,

Hervé


Le vendredi 29 septembre 2023, 14:36:08 CEST Elliotte Rusty Harold a écrit :
> Not a blocker but I did take a quick look at the dependencies. I
> noticed that maven-shared-utils was out of date, but when I tried to
> update it, it failed on verification of the PGP signature of
> commons-io which was now 2.13.0 instead of 2.11.0. This comes from the
> Verify PGP signatures plugin, which I haven't seen before.
> 
> Is this a helpful check? I haven't seen it before, and it definitely
> adds extra work to updating dependencies. If it makes dependencies
> less likely to be kept up to date, that's likely to be a net security
> negative. Is there a string reason to check PGP signatures at build
> time? And if there is, why are we doing this with a fixed map instead
> of looking them up in Maven Central?
> 
> On Fri, Sep 29, 2023 at 2:00 AM Hervé Boutemy  wrote:
> > Hi,
> > 
> > We solved 6 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322;
> > version=12353118=Text
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1992/
> > https://repository.apache.org/content/repositories/maven-1992/org/apache/m
> > aven/plugins/maven-artifact-plugin/3.5.0/maven-artifact-plugin-3.5.0-sourc
> > e-release.zip
> > 
> > Source release checksum(s):
> > maven-artifact-plugin-3.5.0-source-release.zip sha512:
> > 3155f2e3da07752473fe5a2deb5b32f108c2fb1d8cd786718852f18242afad515fafcf557
> > 10f03c136fff9f343702e8e0152d53d51f69f6c043ecc397ce818e1%
> > 
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
> > 
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for at least 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

[VOTE] Release Apache Maven Artifact Plugin version 3.5.0

[Hervé Boutemy]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322=12353118=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1992/
https://repository.apache.org/content/repositories/maven-1992/org/apache/maven/plugins/maven-artifact-plugin/3.5.0/maven-artifact-plugin-3.5.0-source-release.zip

Source release checksum(s):
maven-artifact-plugin-3.5.0-source-release.zip sha512: 
3155f2e3da07752473fe5a2deb5b32f108c2fb1d8cd786718852f18242afad515fafcf55710f03c136fff9f343702e8e0152d53d51f69f6c043ecc397ce818e1%

Staging site:
https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] Release Maven Resolver 1.9.16

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 17 on *nix with umask 
022

Regards,

Hervé

Le vendredi 22 septembre 2023, 20:28:55 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> Note: Maven Resolver 1.x lineage after this release is going into "bugfix
> only" maintenance mode (and will be branched off as maven-resolver-1.9.x),
> while master branch will become 2.x.
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628
> rsion=12353482
> 
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues
> 
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1991
> 
> Source release SHA512:
> b9a03c88bcb21c6bc0af3faf0b8fdf0001e9c2250957f715333e195730350ad5e4519069786f
> 88990f22ac87b7b513d8c84ca5ffbb160ecca2fd0986b89da3da
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.1

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 17 on *nix with umask 
022

Regards,

Hervé

Le jeudi 21 septembre 2023, 21:51:21 CEST Slawomir Jaranowski a écrit :
> Hi,
> 
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921
> rsion=12353341
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20re
> solution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DE
> SC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1990/
> https://repository.apache.org/content/repositories/maven-1990/org/apache/mav
> en/plugins/maven-shade-plugin/3.5.1/maven-shade-plugin-3.5.1-source-release.
> zip
> 
> Source release checksum(s):
> maven-shade-plugin-3.5.1-source-release.zip - SHA-512 :
> 02a72361203356dfccd4a4dca9459e9ef9e7b7e3852500633de920200c3525ef28bdf5e58579
> 1105dbf62ab61050c65300fc1d58495983307ddb58e9562e58c8
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Hervé Boutemy]

+1

Reproducible Build not fully ok: reference build done with JDK 17 on *nix with 
umask 022

maven-javadoc-plugin-3.6.0-source-release.zip is the file that is not 
reproducible: it contains non-reproducible src/it/mrm/3rdparty/_doclet-1.0.jar 
and src/it/mrm/repository/_mjavadoc450-static.jar
I suppose these files should not be there, they are not in Git

IMHO It does not deserve to drop the release, but we should dig into why this 
issue is happening now, it did not happen in the previous releases

Regards,

Hervé

Le mardi 12 septembre 2023, 08:22:43 CEST Henning Schmiedehausen a écrit :
> Hi,
> 
> We solved 16
> issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=123
> 17529=12352956
> 
> There are still a couple of issues left in
> JIRA:https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues
> 
> Staging
> repo:https://repository.apache.org/content/repositories/maven-1989/https://
> repository.apache.org/service/local/repositories/maven-1989/content/org/apac
> he/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-sourc
> e-release.zip
> 
> Source release checksum(s):
> maven-javadoc-plugin-3.6.0-source-release.zip sha512:
> 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e9355
> 4e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4
> 
> Staging
> site:https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
> 
> Guide to testing staged
> releases:https://maven.apache.org/guides/development/guide-testing-releases.
> html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

can you try plexus-xml 3.0.0 and confirm this works as you expected initially, 
please?

Regards,

Hervé

Le mardi 25 juillet 2023, 20:56:04 CEST Slawomir Jaranowski a écrit :
> Hi
> 
> I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
> maven-enforcer 
> 
> In maven-enforcer (and in many other plugins ...) is used, code like:
> 
> Xpp3Dom enforcerRules = Xpp3DomBuilder.build(descriptorStream,
> "UTF-8");
> 
> Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml  but
> Maven 3.x exports
> 
> 
> org.codehaus.plexus.util.xml.Xpp3Dom
> 
> org.codehaus.plexus.util.xml.pull.XmlPullParser ckage>
> 
> org.codehaus.plexus.util.xml.pull.XmlPullParserException xportedPackage>
> 
> org.codehaus.plexus.util.xml.pull.XmlSerializer ckage>
> 
> It is very magical that we export classes but not export artifact
> which contains those classes ...
> 
> so incompatibilite code for Xpp3Dom is used ...
> 
> Any hints on how to process it.





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

plexus-xml 3.0.0 released, compatible with Maven 3

Maven Archetype upgraded as a proof of work:
https://issues.apache.org/jira/browse/ARCHETYPE-648

= upgrading plexus-utils 3 to plexus-utils 4 + plexus-xml 3 (when XML APIs 
required) is a breeze

what has to be avoided is upgrading plexus-xml 3 to 4, as it breaks (for now) 
running your code in Maven 3 but requires Maven 4


Thanks for the feedback, this helped us clarify the plan

Regards,

Hervé

Le dimanche 10 septembre 2023, 18:50:27 CEST Hervé Boutemy a écrit :
> working on it, I created a branch for plexus-xml 3.x:
> https://github.com/codehaus-plexus/plexus-xml/tree/3.x
> 
> we should probably release such plexus-xml 3 that is the "normal" usual XML
> code that we used for years, extracted from plexus-utils 3
> 
> plexus-xml 4 is currently only for Maven 4
> 
> 
> FYI, I tried to upgrade plexus-utils in a few Maven-maintained plugins
> My findings are:
> - many plugins use XML API, sometime just for Xpp3ParserException from Maven
> core API, sometimes because they use Modello to read/write XML...
> then we have many Maven-maintained plugins to test strategies
> 
> - a few plugins don't use XML at all: in this case, upgrading plexus-utils
> from 3 to 4 is feasible just now:
> https://github.com/apache/maven-jarsigner-plugin/pull/12
> 
> Regards,
> 
> Hervé
> 
> Le dimanche 10 septembre 2023, 10:11:14 CEST Sylwester Lachiewicz a écrit :
> > And looks like this apply not only to plugins but also to shared libs for
> > maven (ASF also plexus and mojohous)
> > 
> > Sylwester
> > 
> > niedz., 10 wrz 2023, 09:00 użytkownik Hervé Boutemy
> > 
> > 
> > napisał:
> > > Le samedi 9 septembre 2023, 19:33:51 CEST Václav Haisman a écrit :
> > > > On 25. 07. 23 20:56, Slawomir Jaranowski wrote:
> > > > > Hi
> > > > > 
> > > > > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml
> > > > > 4.x
> > > 
> > > in
> > > 
> > > > > maven-enforcer 
> > > > > 
> > > > > In maven-enforcer (and in many other plugins ...) is used, code 
like:
> > > > >  Xpp3Dom enforcerRules =
> > > > >  Xpp3DomBuilder.build(descriptorStream,
> > > > > 
> > > > > "UTF-8");
> > > > > 
> > > > > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml
> > > > > 
> > > 
> > > but
> > > 
> > > > > Maven 3.x exports
> > > > > 
> > > > >  
> > > 
> > > org.codehaus.plexus.util.xml.Xpp3Dom > > 
> > > > >  e>
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlPullParser > > ed
> > > 
> > > > > Package>
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlPullParserExceptio
> > > n<
> > > 
> > > > > /exportedPackage>
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlSerializer > > ed
> > > 
> > > > > Package>
> > > > > 
> > > > > It is very magical that we export classes but not export artifact
> > > > > which contains those classes ...
> > > > > 
> > > > > so incompatibilite code for Xpp3Dom is used ...
> > > > > 
> > > > > Any hints on how to process it.
> > > > 
> > > > So, what is the takeaway of this tread for casual Maven plugin
> > > > developers like me? Should I avoid plexus-utils 4.x in Maven 3
> > > > plugins?
> > > 
> > > more precisely: don't upgrade plexus-utils to 4 *if you need plexus-xml*
> > > 
> > > our intent of splitting concerns between general non-XML utils vs XML is
> > > a
> > > success: upgrading plexus-utils will make clear which plugins
> > > 
> > > but when you need XML details in your plugin = where Maven core has an
> > > impact,
> > > we are not clear yet on how to make the plexus xml update Maven 3 and 4
> > > compliant at the same time
> > > 
> > > this thread needs to continue because we're not yet at the final
> > > conclusion,
> > > 
> > > but this intermediate small message can be used for now:
> > >   don't upgrade plexus-utils to 4 *if you need plexus-xml*
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

working on it, I created a branch for plexus-xml 3.x:
https://github.com/codehaus-plexus/plexus-xml/tree/3.x

we should probably release such plexus-xml 3 that is the "normal" usual XML 
code that we used for years, extracted from plexus-utils 3

plexus-xml 4 is currently only for Maven 4


FYI, I tried to upgrade plexus-utils in a few Maven-maintained plugins
My findings are:
- many plugins use XML API, sometime just for Xpp3ParserException from Maven 
core API, sometimes because they use Modello to read/write XML...
then we have many Maven-maintained plugins to test strategies

- a few plugins don't use XML at all: in this case, upgrading plexus-utils 
from 3 to 4 is feasible just now:
https://github.com/apache/maven-jarsigner-plugin/pull/12

Regards,

Hervé

Le dimanche 10 septembre 2023, 10:11:14 CEST Sylwester Lachiewicz a écrit :
> And looks like this apply not only to plugins but also to shared libs for
> maven (ASF also plexus and mojohous)
> 
> Sylwester
> 
> niedz., 10 wrz 2023, 09:00 użytkownik Hervé Boutemy 
> 
> napisał:
> > Le samedi 9 septembre 2023, 19:33:51 CEST Václav Haisman a écrit :
> > > On 25. 07. 23 20:56, Slawomir Jaranowski wrote:
> > > > Hi
> > > > 
> > > > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x
> > 
> > in
> > 
> > > > maven-enforcer 
> > > > 
> > > > In maven-enforcer (and in many other plugins ...) is used, code like:
> > > >  Xpp3Dom enforcerRules =
> > > >  Xpp3DomBuilder.build(descriptorStream,
> > > > 
> > > > "UTF-8");
> > > > 
> > > > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml 
> > 
> > but
> > 
> > > > Maven 3.x exports
> > > > 
> > > >  
> > 
> > org.codehaus.plexus.util.xml.Xpp3Dom > 
> > > >  e>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParser > 
> > > > Package>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParserException<
> > 
> > > > /exportedPackage>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlSerializer > 
> > > > Package>
> > > > 
> > > > It is very magical that we export classes but not export artifact
> > > > which contains those classes ...
> > > > 
> > > > so incompatibilite code for Xpp3Dom is used ...
> > > > 
> > > > Any hints on how to process it.
> > > 
> > > So, what is the takeaway of this tread for casual Maven plugin
> > > developers like me? Should I avoid plexus-utils 4.x in Maven 3 plugins?
> > 
> > more precisely: don't upgrade plexus-utils to 4 *if you need plexus-xml*
> > 
> > our intent of splitting concerns between general non-XML utils vs XML is a
> > success: upgrading plexus-utils will make clear which plugins
> > 
> > but when you need XML details in your plugin = where Maven core has an
> > impact,
> > we are not clear yet on how to make the plexus xml update Maven 3 and 4
> > compliant at the same time
> > 
> > this thread needs to continue because we're not yet at the final
> > conclusion,
> > 
> > but this intermediate small message can be used for now:
> >   don't upgrade plexus-utils to 4 *if you need plexus-xml*
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

Le samedi 9 septembre 2023, 19:33:51 CEST Václav Haisman a écrit :
> On 25. 07. 23 20:56, Slawomir Jaranowski wrote:
> > Hi
> > 
> > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
> > maven-enforcer 
> > 
> > In maven-enforcer (and in many other plugins ...) is used, code like:
> >  Xpp3Dom enforcerRules =
> >  Xpp3DomBuilder.build(descriptorStream,
> > 
> > "UTF-8");
> > 
> > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml  but
> > Maven 3.x exports
> > 
> >  
> >  org.codehaus.plexus.util.xml.Xpp3Dom >  e>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParser > Package>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParserException<
> > /exportedPackage>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlSerializer > Package>
> > 
> > It is very magical that we export classes but not export artifact
> > which contains those classes ...
> > 
> > so incompatibilite code for Xpp3Dom is used ...
> > 
> > Any hints on how to process it.
> 
> So, what is the takeaway of this tread for casual Maven plugin
> developers like me? Should I avoid plexus-utils 4.x in Maven 3 plugins?

more precisely: don't upgrade plexus-utils to 4 *if you need plexus-xml*

our intent of splitting concerns between general non-XML utils vs XML is a 
success: upgrading plexus-utils will make clear which plugins 

but when you need XML details in your plugin = where Maven core has an impact, 
we are not clear yet on how to make the plexus xml update Maven 3 and 4 
compliant at the same time

this thread needs to continue because we're not yet at the final conclusion, 
but this intermediate small message can be used for now:
  don't upgrade plexus-utils to 4 *if you need plexus-xml*

Regards,

Hervé



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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

now that plexus-xml has more details, I see the key point causing the most 
issues: it uses not only maven-xml-api but also maven-xml-impl

maven-xml-impl is the Maven 4-specific reimplementation of XML parsing that is 
causing the incompatibility

probably that this Maven XML Implementation component should be added to the 
list of libraries that deserve extracting from Maven core release cycle to 
have a dedicated Maven Shared Component. This won't solve the compatibility 
issue that started this thread, but a least go in the right direction by 
making things more clear: today, it's too much magic and inter-dependencies 
with Maven core

Here is the list of Maven core components that should IMHO be extracted as 
separate Maven Shared Component:
- Meta Annotation:
  https://maven.apache.org/ref/4.0.0-alpha-7/api/maven-api-meta/index.html
- XML API:
  https://maven.apache.org/ref/4.0.0-alpha-7/api/maven-api-xml/index.html
- XML Impl:
  https://maven.apache.org/ref/4.0.0-alpha-7/maven-xml-impl/index.html

The discussion on plexus-xml compatibility with Maven 3 will required a next 
thinking: perhaps we should have had a plexus-xml release that was done 
*before* maven-xml-impl update = what is causing the compatibility issue

Regards,

Hervé

Le samedi 9 septembre 2023, 11:33:59 CEST Hervé Boutemy a écrit :
> > o.c.p:p-u 4.x that depends on
> > -> o.c.p:p-xml 4 that depends on
> 
> notice this dependency is *optional*
> it's useful only for ReaderFactory/WriterFactory, for XmlReader/Writer
> fully removing the dependency would have broken full compatibility by
> removing a few methods: it was preferred to mark the dependency as optional
> and keep full compatibility
> 
> then I would not say that p-u 4 pulls new Maven 4 API
> 
> > -> o.c.p:p-xml 4 that depends on
> > -> o.a.m:m-api-xml that depends on
> > -> o.a.m:m-api-meta
> 
> to me, here is where an improvement would be useful
> m-api-meta and m-api-xml are small very stable APIs, very non-Maven core
> specific
> I understand that we want to put them at Apache instead of Plexus, and I
> agree.
> But I think we should make their release cycle independent from Maven core:
> they do not deserve the current 7 alphas, then new releases in the future
> years.
> 
> see https://maven.apache.org/ref/4.0.0-alpha-7/api/index.html for an
> overview of all Maven 4 API artifacts:
> - Model, Settings, Toolchains and Core are clearly here at their right place
> - XML (1 interface: XmlNode) and meta annotation (6 annotations) are not so
> much Maven core related, and stable enough
> 
> IMHO, XML and meta annotation should fo to Maven Shared Components
> https://maven.apache.org/shared/index.html
> Better place, and better release cycle
> 
> then depending on these from outside would not be problematic
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 8 septembre 2023, 19:42:40 CEST Tamás Cservenák a écrit :
> > Howdy,
> > 
> > Basil's issue is made me realize:
> > o.c.p:p-u 4.x that depends on
> > -> o.c.p:p-xml 4 that depends on
> > -> o.a.m:m-api-xml that depends on
> > -> o.a.m:m-api-meta
> > 
> > This means that p-u pulls in new Maven4 API bits.
> > Hence, Maven 3 plugin, that is built against maven-plugin-api 3.x, if
> > switched to p-u 4, would start receiving bits of Maven4 new API...
> > 
> > This is a big no for me, not to mention how this can prove problematic
> > down
> > the road too:
> > this means that today (as all this is "just on CP") mvn3 plugin could use
> > bits of Maven4 API that later -- if run in Maven4 -- becomes
> > forbidden/unavailable...
> > 
> > So, IMHO this just proves, that Maven 3.x level plugins should stick with
> > p-u 3.x
> > 
> > On Fri, Sep 8, 2023 at 6:24 PM Basil Crow  wrote:
> > > I raised this issue in
> > > 
> > > https://github.com/jenkinsci/maven-hpi-plugin/pull/490#issuecomment-1557
> > > 97
> > > 0717 but did not receive a response.
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

ok, I updated plexus-utils and plexus-xml sites
and added a few key aspects about how these relate to old Plexus Utils 3

https://codehaus-plexus.github.io/plexus-utils/
https://codehaus-plexus.github.io/plexus-xml/

I hope this will help

Le samedi 9 septembre 2023, 11:14:52 CEST Hervé Boutemy a écrit :
> yes
> notice p-u site is broken https://codehaus-plexus.github.io/plexus-utils/
> and we should probably also find a way to publish also latest  p-u 3 javadoc
> in parallel
> 
> I'll see what I can do also to help on this
> 
> Le vendredi 8 septembre 2023, 10:53:11 CEST Slawomir Jaranowski a écrit :
> > Thanks, I will create an IT for it.
> > 
> > Good idea to describe the migration from plexus 3.x to 4.x.
> > 
> > pt., 8 wrz 2023 o 10:26 Guillaume Nodet  napisał(a):
> > > I've raised MNG-7873.
> > > Slawomir, do you think you could create an IT for that ?
> > > I'll try to provide a fix asap, but a clean IT would make sure the
> > > problem
> > > is actually fixed.
> > > 
> > > I think we should also update the plexus-utils release notes with some
> > > more
> > > information about the migration to 4.x when using the xml bits.
> > > 
> > > [1] https://issues.apache.org/jira/browse/MNG-7873
> > > 
> > > Le lun. 4 sept. 2023 à 22:50, Guillaume Nodet  a
> > > écrit
> > > 
> > > > I think the decision to not export plexus-utils was taken some time
> > > > ago.
> > > > 
> > > > Unfortunately, the xml bits still have to be provided by the maven
> > > > core
> > > > class loader.
> > > > I think in this case, Maven 3.9.x should also expose the builder class
> > > 
> > > org.codehaus.plexus.util.xml.Xpp3DomBuilder > > ck
> > > age>>
> > > 
> > > > I think this should work, but this would only solve the problem for
> > > > the
> > > > latest 3.9.x maven, not older versions.
> > > > 
> > > > 
> > > > Le mar. 25 juil. 2023 à 20:56, Slawomir Jaranowski <
> > > 
> > > s.jaranow...@gmail.com>
> > > 
> > > > a écrit :
> > > >> Hi
> > > >> 
> > > >> I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml
> > > >> 4.x
> > > 
> > > in
> > > 
> > > >> maven-enforcer 
> > > >> 
> > > >> In maven-enforcer (and in many other plugins ...) is used, code like:
> > > >> Xpp3Dom enforcerRules =
> > > 
> > > Xpp3DomBuilder.build(descriptorStream,
> > > 
> > > >> "UTF-8");
> > > >> 
> > > >> Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml
> > > >> 
> > > 
> > > but
> > > 
> > > >> Maven 3.x exports
> > > >> 
> > > >> 
> > > >> 
> > > >> org.codehaus.plexus.util.xml.Xpp3Dom > > >> e>
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlPullParser > > ed
> > > Package>
> > > 
> > > 
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlPullParserExceptio
> > > n<
> > > /exportedPackage>
> > > 
> > > 
> > > 
> > > org.codehaus.plexus.util.xml.pull.XmlSerializer > > ed
> > > Package>>
> > > 
> > > >> It is very magical that we export classes but not export artifact
> > > >> which contains those classes ...
> > > >> 
> > > >> so incompatibilite code for Xpp3Dom is used ...
> > > >> 
> > > >> Any hints on how to process it.
> > > >> 
> > > >> --
> > > >> Sławomir Jaranowski
> > > > 
> > > > --
> > > > 
> > > > Guillaume Nodet
> > > 
> > > --
> > > 
> > > Guillaume Nodet
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

> o.c.p:p-u 4.x that depends on
> -> o.c.p:p-xml 4 that depends on
notice this dependency is *optional*
it's useful only for ReaderFactory/WriterFactory, for XmlReader/Writer
fully removing the dependency would have broken full compatibility by removing 
a few methods: it was preferred to mark the dependency as optional and keep 
full compatibility

then I would not say that p-u 4 pulls new Maven 4 API

> -> o.c.p:p-xml 4 that depends on
> -> o.a.m:m-api-xml that depends on
> -> o.a.m:m-api-meta
to me, here is where an improvement would be useful
m-api-meta and m-api-xml are small very stable APIs, very non-Maven core 
specific
I understand that we want to put them at Apache instead of Plexus, and I 
agree.
But I think we should make their release cycle independent from Maven core: 
they do not deserve the current 7 alphas, then new releases in the future 
years.

see https://maven.apache.org/ref/4.0.0-alpha-7/api/index.html for an overview 
of all Maven 4 API artifacts:
- Model, Settings, Toolchains and Core are clearly here at their right place
- XML (1 interface: XmlNode) and meta annotation (6 annotations) are not so 
much Maven core related, and stable enough

IMHO, XML and meta annotation should fo to Maven Shared Components
https://maven.apache.org/shared/index.html
Better place, and better release cycle

then depending on these from outside would not be problematic

Regards,

Hervé

Le vendredi 8 septembre 2023, 19:42:40 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> Basil's issue is made me realize:
> o.c.p:p-u 4.x that depends on
> -> o.c.p:p-xml 4 that depends on
> -> o.a.m:m-api-xml that depends on
> -> o.a.m:m-api-meta
> 
> This means that p-u pulls in new Maven4 API bits.
> Hence, Maven 3 plugin, that is built against maven-plugin-api 3.x, if
> switched to p-u 4, would start receiving bits of Maven4 new API...
> 
> This is a big no for me, not to mention how this can prove problematic down
> the road too:
> this means that today (as all this is "just on CP") mvn3 plugin could use
> bits of Maven4 API that later -- if run in Maven4 -- becomes
> forbidden/unavailable...
> 
> So, IMHO this just proves, that Maven 3.x level plugins should stick with
> p-u 3.x
> 
> On Fri, Sep 8, 2023 at 6:24 PM Basil Crow  wrote:
> > I raised this issue in
> > 
> > https://github.com/jenkinsci/maven-hpi-plugin/pull/490#issuecomment-155797
> > 0717 but did not receive a response.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

yes
notice p-u site is broken https://codehaus-plexus.github.io/plexus-utils/
and we should probably also find a way to publish also latest  p-u 3 javadoc in 
parallel

I'll see what I can do also to help on this

Le vendredi 8 septembre 2023, 10:53:11 CEST Slawomir Jaranowski a écrit :
> Thanks, I will create an IT for it.
> 
> Good idea to describe the migration from plexus 3.x to 4.x.
> 
> pt., 8 wrz 2023 o 10:26 Guillaume Nodet  napisał(a):
> > I've raised MNG-7873.
> > Slawomir, do you think you could create an IT for that ?
> > I'll try to provide a fix asap, but a clean IT would make sure the problem
> > is actually fixed.
> > 
> > I think we should also update the plexus-utils release notes with some
> > more
> > information about the migration to 4.x when using the xml bits.
> > 
> > [1] https://issues.apache.org/jira/browse/MNG-7873
> > 
> > Le lun. 4 sept. 2023 à 22:50, Guillaume Nodet  a écrit
> > 
> > > I think the decision to not export plexus-utils was taken some time ago.
> > > 
> > > Unfortunately, the xml bits still have to be provided by the maven core
> > > class loader.
> > > I think in this case, Maven 3.9.x should also expose the builder class
> > 
> > org.codehaus.plexus.util.xml.Xpp3DomBuilder > age>> 
> > > I think this should work, but this would only solve the problem for the
> > > latest 3.9.x maven, not older versions.
> > > 
> > > 
> > > Le mar. 25 juil. 2023 à 20:56, Slawomir Jaranowski <
> > 
> > s.jaranow...@gmail.com>
> > 
> > > a écrit :
> > >> Hi
> > >> 
> > >> I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x
> > 
> > in
> > 
> > >> maven-enforcer 
> > >> 
> > >> In maven-enforcer (and in many other plugins ...) is used, code like:
> > >> Xpp3Dom enforcerRules =
> > 
> > Xpp3DomBuilder.build(descriptorStream,
> > 
> > >> "UTF-8");
> > >> 
> > >> Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml 
> > 
> > but
> > 
> > >> Maven 3.x exports
> > >> 
> > >> 
> > >> 
> > >> org.codehaus.plexus.util.xml.Xpp3Dom
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParser > Package>
> > 
> > 
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParserException<
> > /exportedPackage>
> > 
> > 
> > 
> > org.codehaus.plexus.util.xml.pull.XmlSerializer > Package>> 
> > >> It is very magical that we export classes but not export artifact
> > >> which contains those classes ...
> > >> 
> > >> so incompatibilite code for Xpp3Dom is used ...
> > >> 
> > >> Any hints on how to process it.
> > >> 
> > >> --
> > >> Sławomir Jaranowski
> > > 
> > > --
> > > 
> > > Guillaume Nodet
> > 
> > --
> > 
> > Guillaume Nodet





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

Re: plexus-utils 4.x and Xpp3DomBuilder

[Hervé Boutemy]

right conclusion

Le mercredi 26 juillet 2023, 06:55:10 CEST Christoph Läubrich a écrit :
> I tried the same with Tycho and the conclusion was that a maven plugin
> can currently not upgrade to plexus-xml4 if you still want to support
> maven 3.x
> 
> Am 25.07.23 um 20:56 schrieb Slawomir Jaranowski:
> > Hi
> > 
> > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
> > maven-enforcer 
> > 
> > In maven-enforcer (and in many other plugins ...) is used, code like:
> >  Xpp3Dom enforcerRules =
> >  Xpp3DomBuilder.build(descriptorStream,
> > 
> > "UTF-8");
> > 
> > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml  but
> > Maven 3.x exports
> > 
> >  
> >  org.codehaus.plexus.util.xml.Xpp3Dom >  e>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParser > Package>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlPullParserException<
> > /exportedPackage>
> > 
> > org.codehaus.plexus.util.xml.pull.XmlSerializer > Package>
> > 
> > It is very magical that we export classes but not export artifact
> > which contains those classes ...
> > 
> > so incompatibilite code for Xpp3Dom is used ...
> > 
> > Any hints on how to process it.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: CVE-2021-26291 for plugin writers

[Hervé Boutemy]

in fact, whatever you do in your plugin POM, they are provided by Maven core 
at runtime (ignoring the precise version the plugin asked for)

but marking them provided in your plugin pom.xml makes this fact more visible

Regards,

Hervé

Le jeudi 31 août 2023, 03:15:15 CEST Jeremy Landis a écrit :
> Make sure your maven artifacts are provided scope then your users can
> continue using old versions just fine to the 3.3.9 support level you have
> now.
> 
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android
> 
> From: Anton Vodonosov 
> Sent: Monday, August 28, 2023 11:14:30 AM
> To: dev@maven.apache.org 
> Subject: CVE-2021-26291 for plugin writers
> 
> Maven 3.8.1 release notes describe CVE-2021-26291 fixed in that version:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apach
> e.org%2Fdocs%2F3.8.1%2Frelease-notes.html=05%7C01%7C%7Cfb1603297a0149d3
> 585e08dba7d986e8%7C84df9e7fe9f640afb435%7C1%7C0%7C63828832493462
> 1732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=EYAH%2FA7JWCBPcZ%2F4wNuUVHJCiNcrh0
> oB1C8cYeIDhu0%3D=0 s.html>
> 
> That's the best explanation of this CVE of all I saw online.
> 
> But it misses guide for plugin authors.
> 
> GitHub's security scanner created this alert for my plugin
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Favodonosov%2Fhashver-maven-plugin%2Fsecurity%2Fdependabot%2F3=05%7C01
> %7C%7Cfb1603297a0149d3585e08dba7d986e8%7C84df9e7fe9f640afb435%7C
> 1%7C0%7C638288324934621732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rB3V4hX6%2Ba
> N9B8yhv7yrQolTXDL7USf0VkLn75fFvmU%3D=0 v/hashver-maven-plugin/security/dependabot/3> and a corresponding pull
> request, where it suggest to change
> dependency maven-core from 3.3.8 to 3.8.1:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Favodonosov%2Fhashver-maven-plugin%2Fpull%2F11=05%7C01%7C%7Cfb1603297a
> 0149d3585e08dba7d986e8%7C84df9e7fe9f640afb435%7C1%7C0%7C63828832
> 4934621732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=09QeFG3AtERkHZAQ0Wyd%2BjIJMa
> YQmYqf8qoNl20K%2FZ4%3D=0 n-plugin/pull/11>
> 
> I am reluctant to commit this change because
> I am afraid the plugin may stop working for users of older maven versions.
> I suppose this CVE is not relevant to plugin authors, my reasoning
> is in the pull request comments.
> 
> Am I right that the CVE does not affect the plugin?
> 
> It would be good if the 3.8.1 release notes were extended with explanations
> is it safe for plugins to depend on older versions of maven libs.
> 
> Best regards,
> - Anton
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Multi-repo experience

[Hervé Boutemy]

notice that you call it "multi-repo experience"
it's in fact more about a topic of component-oriented structure, each 
component having its own release lifecycle. The fact that each component has 
his own Git repository is just an implementation detail (in the past, each 
component had its own root directory in Subversion: see [1] for how we went 
from svn structure to Git one).

> Would you still go the same route if Maven is founded today?
yes: Maven is a core, with plugins (and extension) = something we would not 
change without loosing critical aspects of Maven
and the fact that some plugins reuse some shared components is normal

of course, the exact number of plugins and shared components could have been 
done with different granularity

And on using Google repo tool and the precise directory organisation when 
checking out everything, it's an implementation detail:
https://github.com/apache/maven-sources/tree/master
Changing anything here can be done, it's not critical: what is critical is the 
component-oriented approach. Then the granularity chosen for these components.

Regards,

Hervé

[1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration

Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
> Hi Volkan,
> 
> Yes, I worked a lot on this aspect fo Maven: the result is summarised here
> https://maven.apache.org/scm.html
> 
> As you can see, you can get "Maven Full Sources" in one command using Google
> "repo" tool.
> 
> Please have a llok and we can dive into more details if you need
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> > Hello,
> > 
> > Log4j crew is considering moving to a multi-repo structure. If I am not
> > mistaken, there are 125 `github.com/apache/maven-*`
> > <http://github.com/apache/maven-*> repos, which makes me believe that you
> > have quite a bit of experience with such a construct. I am curious to hear
> > your thoughts on the matter.
> > 
> > How does it work for you?
> > What are its advantages?
> > What are its disadvantages?
> > What are the things we should be extra cautious about?
> > Are there any major pillars we need to erect for such a construct to work?
> > Would you still go the same route if Maven is founded today?
> > 
> > I deliberately don't share in this post our goals with such a migration to
> > avoid manipulating your line of thinking. I can do that later to give the
> > conversation a little bit more context.
> > 
> > Kind regards.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Multi-repo experience

[Hervé Boutemy]

Hi Volkan,

Yes, I worked a lot on this aspect fo Maven: the result is summarised here
https://maven.apache.org/scm.html

As you can see, you can get "Maven Full Sources" in one command using Google 
"repo" tool.

Please have a llok and we can dive into more details if you need

Regards,

Hervé

Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> Hello,
> 
> Log4j crew is considering moving to a multi-repo structure. If I am not
> mistaken, there are 125 `github.com/apache/maven-*`
>  repos, which makes me believe that you
> have quite a bit of experience with such a construct. I am curious to hear
> your thoughts on the matter.
> 
> How does it work for you?
> What are its advantages?
> What are its disadvantages?
> What are the things we should be extra cautious about?
> Are there any major pillars we need to erect for such a construct to work?
> Would you still go the same route if Maven is founded today?
> 
> I deliberately don't share in this post our goals with such a migration to
> avoid manipulating your line of thinking. I can do that later to give the
> conversation a little bit more context.
> 
> Kind regards.





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

Re: [CANCELED][VOTE] Release Apache Maven 3.9.4

[Hervé Boutemy]

you probably rebuilt the release with "mvn install" = what you need to avoid
and it seems the rebuild was done with an environment that did not give you the 
same output as the reference build

FYI, I was able to rebuild Maven Resolver 1.9.14 with the same output as you
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/maven/resolver/maven-resolver/README.md

AFAIK, there is no reproduciblity issue nowadays with recent Bnd and/or Felix 
Bundle plugin

Regards,

Hervé

Le samedi 29 juillet 2023, 15:19:12 CEST Tamás Cservenák a écrit :
> Sure,
> 
> Will do that, thanks.
> 
> What I don't understand is how I got 2 different jars in the first place,
> as i did not release twice (nor build from tag two times)...
> 
> T
> 
> On Sat, Jul 29, 2023, 11:58 Herve Boutemy  wrote:
> > notice that you don't need to go to 3.9.5: rebuilding 3.9.4 from a clean
> > local repository and Git checkout from tag with `mvn -Papache-release
> > deploy` will do the job that has to be re-done
> > 
> > Regards,
> > 
> > Hervé
> > 
> > On 2023/07/29 08:47:48 Tamás Cservenák wrote:
> > > Am cancelling the vote due Herve -1
> > > 
> > > Will need to figure out how this happened.
> > > 
> > > T
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Maven Resolver 1.9.13

[Hervé Boutemy]

+1

Reproducible Build ok: reference done on *nix with JDK 17 and umask 022

Regards,

Hervé

Le jeudi 22 juin 2023, 11:47:30 CEST Slawomir Jaranowski a écrit :
> +1
> 
> wt., 20 cze 2023 o 16:13 Tamás Cservenák  napisał(a):
> > Howdy,
> > 
> > We solved 2 issues:
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628;
> > version=12353352
> > 
> > There are still some issues in JIRA:
> > https://issues.apache.org/jira/projects/MRESOLVER/issues
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/maven-1966/
> > 
> > Source release SHA512:
> > 
> > 02e1dfe142e7ce2d1fc2f57ffeac461f9a21ac79e6b267e5f0f368e629d82d89da33d21796
> > a0f9e2f52b73710ab98cb08dee8c392b6a5dd250dc4d27a9c50652
> > 
> > Staging site:
> > https://maven.apache.org/resolver-archives/resolver-LATEST/
> > 
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1





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

Re: [DISCUSS] POM model version

[Hervé Boutemy]

Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit :
> Le dim. 18 juin 2023 à 21:14, Hervé Boutemy  a
> 
> écrit :
> > I now understand our divergence: you implicitely use Maven 4 with some
> > updates
> > already done on xsd versions that I did not know about, and I don't yet
> > understand what has already be done on build vs consumer POM
> > transformation
> > 
> > First, having some feedback from people on the idea of using plugin
> > execution
> > priority would be useful, because even before diving into implementation
> > details, this approach is to be accepted.
> > 
> > If devs agree on the introduction of basic priority, we have 3 ways to
> > implement its introduction:
> > 
> > 1. Maven 3 way = add as an XML attribute: 
> > Fully compatible with current Maven Central conventions, no need to change
> > anything
> > done in https://github.com/apache/maven/pull/1173
> > as you can see, it's a modification of 2 lines + some documentation
> 
> Yes, but again, you say it's compatible because you add an attribute vs
> element.  This isn't supported by any facts so far: in my mind, and in the
> model parser used by maven, and in the xml schema spec, there's no
> difference between adding an attribute and adding an element. With that in
> mind, I find this solution (adding an attribute vs adding an element) very
> inconsistent (because we don't use attributes in the schema but in a very
> few places) with no real benefits. And yes, it's two lines, but that's an
> abuse of the xml schema, because we will have to publish a newly modified
> schema while saying it's the same as before.  How will people actually know
> if they have the correct one or not ?
please listen: it is a convention at Maven level defined for Maven 3.5.0 
(2017), based on the fact that we don't know the code that consumes Maven 
Central
You're right: not facts based on Maven core, a compromise, not clean, you were 
not there, you just need to accept that this is history, it exists, has 
reasons, is not fully stupid even if far from perfect, and you can't change it 
just at Maven core level.
The benefit is not for us on Maven core, but for the many unknown code that 
uses pom.xml from Maven Central for 20 years

> We're using checksums and all sort
> of things for artifacts, but we'd overwrite an existing published schema in
> a blink ? We don't even want to remove tags of unpublished releases and we
> wouldn't be scared about overwriting a schema ?  and I'm not being
> sarcastic, I do really find that dodgy and weird that we would want to go
> that way.
It's a pure technical "purity" reaction that I fully respect: yes, this 
compromise is dodgy from a technical point of view, but it proved to work (it 
did not break the Maven Central ecosystem consuming *.pom nor the Maven users 
writing pom.xml).
This convention has been defined in 2017, after many years searching how to 
evolve without breaking our Maven Central consumer ecosystem, with the level 
of unknown involved into judging what can reasonably be done.
This step lead later to build/consumer idea, and 2 steps:
1. update build content, but not consumer = what is called Maven 4
2. update consumer content (ie in Maven Central) = what is called Maven 5 = 
the real target that will permit to solve our management of unknown POM v4 
consumers land that won't disappear and that we don't want to break.
If we introduce now some updates that were named Maven 5, I'm just trying to 
make sure we adapt our energy  on sharing and checking to the increased risk 
on the whole ecosystem: as you already saw, there are edge cases at least on 
parent POMs that need to be published to Maven Central

> 
> > tested with a sample project:
> > https://github.com/hboutemy/MNG-7804-plugin-execution-priority
> > 
> > 2. the Maven 5 way: add a new XML element, and manage the fact that it
> > will
> > change all the expectations from a Maven Central perspective
> > = what we were supposed to do in the future, once people have some
> > experience
> > with Maven 4 and build vs consumer POM, plus all what is required to be
> > added
> > as constraints at maven Central level
> 
> What I'm trying to say is that I don't understand why we'd need maven 4 +
> maven 5.  The consumer POM and the definition of a new schema are two
> separate things and could be both done in maven 4.  Also, I don't think it
> has been described exactly when/how the POM 5 would be used.  That's what
> I'm trying to do in this discussion (if we can just forget about the
> numbers, because they have again no real meaning).
Maven 5 term is about making more evolution to the POM schema than adding a 
few attributes only: this has been the convention until now

Re: [DISCUSS] POM model version

[Hervé Boutemy]

I now understand our divergence: you implicitely use Maven 4 with some updates 
already done on xsd versions that I did not know about, and I don't yet 
understand what has already be done on build vs consumer POM transformation

First, having some feedback from people on the idea of using plugin execution 
priority would be useful, because even before diving into implementation 
details, this approach is to be accepted.

If devs agree on the introduction of basic priority, we have 3 ways to 
implement its introduction:

1. Maven 3 way = add as an XML attribute: 
Fully compatible with current Maven Central conventions, no need to change 
anything
done in https://github.com/apache/maven/pull/1173
as you can see, it's a modification of 2 lines + some documentation

tested with a sample project:
https://github.com/hboutemy/MNG-7804-plugin-execution-priority

2. the Maven 5 way: add a new XML element, and manage the fact that it will 
change all the expectations from a Maven Central perspective
= what we were supposed to do in the future, once people have some experience 
with Maven 4 and build vs consumer POM, plus all what is required to be added 
as constraints at maven Central level

3. the Maven 4 way: here, I still don't get what has been already done on POM 
xmlns, POM xsd, and what is published to Maven Central
But clearly, it already opens many questions to be seriously understood on 
build vs consumer POM and how this new field goes (or not) to Maven Central in 
a compatible way. Maven 4 was not supposed to change anything at Maven Central 
level.


option 2 or 3 give me headaches
The PR remains small https://github.com/apache/maven/pull/1147
but it is clearly defining many new ways of handling POM evolution both 
internally (build vs consumer) and externally for Maven Central

if one of these is chosen, I ask everybody to seriously work on it and 
document all the new aspects that this reveals
Don't just say "nice"

Regards,

Hervé


Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit :
> Le ven. 16 juin 2023, 19:20, Hervé Boutemy  a écrit :
> > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > > I think this is exactly what Hervé explains was rejected years ago.  The
> > > assumption is that the POM v4 is "set in amber" and will never change,
> > > at
> > > least for the consumer side, i.e. defining dependencies.  For the build
> > > side, it has to evolve, so the POM v5 will need a different schema url
> > > or
> > > 
> > > version.  But imho the goals are:
> > >   * make sure we keep POM v4 the way it is to tools for consumers
> > >   * allow some room for POM v5 on the build side
> > > 
> > > However, the problem I see is that when you deploy a "pom" package, i.e.
> > 
> > a
> > 
> > > parent POM that may be used as a parent for other projects, we clearly
> > 
> > have
> > 
> > > a problem for which I do not  really have a clear understanding how to
> > > solve.  Let's assume this POM uses a POM v5 new feature, so that the
> > > semantic data carried by this POM can not be written with a POM v4.
> > 
> > Such a
> > 
> > > POM can not be uploaded to maven central in the v4 form, so it WILL
> > > break
> > > tools, but I don't really see any other way.
> > > 
> > > So here's what I propose:
> > >   * further trim down the consumer POM as it was envisioned years ago in
> > > 
> > > [1] and [2] (the removed data will still be available for other tools to
> > > consume, see below)
> > > 
> > >   * we want to relax the constraints of the v4 pom schema a bit to be
> > 
> > able
> > 
> > > to validate the current build pom (where a few things are inferred)
> > > 
> > >   * for packaged artifacts, we will upload the consumer POM v4 as the
> > 
> > main
> > 
> > > POM and the normalized POM v4/v5  as an attached artifact
> > > 
> > >   * for the "pom" package, we will upload the normalized POM v4/v5 as
> > >   the
> > > 
> > > main POM (no consumer POM)
> > > 
> > > In the short term we could then:
> > >   * allow the definition of POM v4.x, i.e. small evolutions with a
> > >   schema
> > > 
> > > compatible to v4 (i.e. mostly new elements / attributes) that will give
> > > a
> > > bit of freedom to implement new stuff (i.e. we should start properly
> > > versioning it and communicate to the community that they will have to
> > 
> > adapt
> > 
> > > their tools)
> > > 
> > >   * when deploying the

Re: [VOTE] Release Maven Resolver 1.9.12

[Hervé Boutemy]

yes, same happened in 1.9.11: this is where I found this first, while checking 
for Reproducible Central

https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/maven/resolver/maven-resolver/README.md


Yes, dropping your local repo would be nice to avoid such unexpected state

Lately, umask has been a pain to Reproducible Builds: it gives much weight to 
an environment aspect, with Linux distros changing their default value recently.


On Resolver 1.9.12, we have now multiple options:
1. drop 1.9.12 and go to 1.9.13: looks overkill to me
2. let 1.9.12 binaries as is: reasonable
3. rebuild a new staging repository from Git tag: I'd love this one to be at 
least thought a little bit before saying no

Explanation:
Given in reality the build itself is reproducible, but the reference build has 
just one file broken by your desktop environment, it means that if you "mvn 
-Papache-release deploy" from the Git tag, you'll get a new staging repository 
that will contain the same binaries (in particular the same 
-source-release.ziip and its sha512), just with a fixed 
maven-resolver-named-locks-redisson-1.9.12-bundle.zip
The real files that will be different are the .asc files
We could later decide if we release to Maven Central from current maven-1962 or 
the new one

Are you ready to try? (and discover one of the nice benefit of Reproducible 
Builds...)

Regards,

Hervé

Le vendredi 16 juin 2023, 19:23:14 CEST Tamás Cservenák a écrit :
> Found it: that above is my laptop, while I did (both) release on my desktop:
> 
> [cstamas@urnebes ~]$ cd .m2/repository-oss/org/objenesis/objenesis/3.3/
> [cstamas@urnebes 3.3]$ ll
> total 68
> -rw---. 1 cstamas cstamas 49423 2022 dec   15 objenesis-3.3.jar
> -rw---. 1 cstamas cstamas40 2022 dec   15 objenesis-3.3.jar.sha1
> -rw---. 1 cstamas cstamas  3007 2022 dec   15 objenesis-3.3.pom
> -rw---. 1 cstamas cstamas40 2022 dec   15 objenesis-3.3.pom.sha1
> -rw---. 1 cstamas cstamas   192 2022 dec   15 _remote.repositories
> [cstamas@urnebes 3.3]$
> 
> Hence, the same should be true for 1.9.11 as well. Also, it seems it's time
> to nuke my local repo ;)
> 
> Thanks
> T
> 
> On Fri, Jun 16, 2023 at 7:16 PM Tamás Cservenák  wrote:
> > Strange
> > 
> > [cstamas@blondie ~]$ cd .m2/repository-oss/org/objenesis/objenesis/3.3/
> > [cstamas@blondie 3.3]$ ll
> > total 68
> > -rw-r--r--. 1 cstamas cstamas 49423 dec   20 17.30 objenesis-3.3.jar
> > -rw-r--r--. 1 cstamas cstamas40 dec   20 17.30 objenesis-3.3.jar.sha1
> > -rw-r--r--. 1 cstamas cstamas  3007 dec   20 17.30 objenesis-3.3.pom
> > -rw-r--r--. 1 cstamas cstamas40 dec   20 17.30 objenesis-3.3.pom.sha1
> > -rw-r--r--. 1 cstamas cstamas   192 dec   20 17.30 _remote.repositories
> > [cstamas@blondie 3.3]$
> > 
> > Herve, while at this, please can you check 1.9.11 as well? IMHO there must
> > be the same issue present, or if not, am even more puzzled...
> > 
> > T
> > 
> > On Fri, Jun 16, 2023 at 7:13 PM Hervé Boutemy 
> > 
> > wrote:
> >> +1
> >> 
> >> notice that Reproducible Builds is NOT ok on 1 file: reference build done
> >> on
> >> *nix with JDK 17 and umask 022
> >> 
> >> the only issue is in
> >> maven-resolver-named-locks-redisson-1.9.12-bundle.zip:
> >> │--rw---  2.0 unx49423 b- defN 23-Jun-16 13:32 objenesis-3.3.jar
> >> │+-rw-r--r--  2.0 unx49423 b- defN 23-Jun-16 13:32 objenesis-3.3.jar
> >> it seems your local repository contains a objenesis-3.3.jar which is not
> >> group
> >> nor world wide readable
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le vendredi 16 juin 2023, 15:57:43 CEST Tamás Cservenák a écrit :
> >> > Howdy,
> >> 
> >> > We solved 1 issue:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628
> >> >> 
> >> > rsion=12353340
> >> > 
> >> > There are still some issues in JIRA:
> >> > https://issues.apache.org/jira/projects/MRESOLVER/issues
> >> > 
> >> > Staging repository:
> >> > https://repository.apache.org/content/repositories/maven-1962/
> >> 
> >> > Source release SHA512:
> >> b24cbd998e1739a89eb693b764fef9f476d53a5b1546ffb87941afcdc9c76bdcd69cbf924
> >> 782>> 
> >> > ded6067388679446c25c166364cd9ac450e8ef17a70d3f1045ce
> >> > 
> >> > Staging site:
> >> > https://maven.apache.org/resolver-archives/resolver-LATEST/
> >> > 
> >> > Guide to testing staged releases:
> >> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >> > 
> >> > Vote open for 72 hours.
> >> > 
> >> > [ ] +1
> >> > [ ] +0
> >> > [ ] -1
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [DISCUSS] POM model version

[Hervé Boutemy]

Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> I think this is exactly what Hervé explains was rejected years ago.  The
> assumption is that the POM v4 is "set in amber" and will never change, at
> least for the consumer side, i.e. defining dependencies.  For the build
> side, it has to evolve, so the POM v5 will need a different schema url or
> version.  But imho the goals are:
>   * make sure we keep POM v4 the way it is to tools for consumers
>   * allow some room for POM v5 on the build side
> 
> However, the problem I see is that when you deploy a "pom" package, i.e. a
> parent POM that may be used as a parent for other projects, we clearly have
> a problem for which I do not  really have a clear understanding how to
> solve.  Let's assume this POM uses a POM v5 new feature, so that the
> semantic data carried by this POM can not be written with a POM v4.  Such a
> POM can not be uploaded to maven central in the v4 form, so it WILL break
> tools, but I don't really see any other way.
> 
> So here's what I propose:
>   * further trim down the consumer POM as it was envisioned years ago in
> [1] and [2] (the removed data will still be available for other tools to
> consume, see below)
>   * we want to relax the constraints of the v4 pom schema a bit to be able
> to validate the current build pom (where a few things are inferred)
>   * for packaged artifacts, we will upload the consumer POM v4 as the main
> POM and the normalized POM v4/v5  as an attached artifact
>   * for the "pom" package, we will upload the normalized POM v4/v5 as the
> main POM (no consumer POM)
> 
> In the short term we could then:
>   * allow the definition of POM v4.x, i.e. small evolutions with a schema
> compatible to v4 (i.e. mostly new elements / attributes) that will give a
> bit of freedom to implement new stuff (i.e. we should start properly
> versioning it and communicate to the community that they will have to adapt
> their tools)
>   * when deploying the v4/v5 POM as the main POM (i.e. for pom packages),
> we could be smart enough to see if the POM requires non v4 features and if
> that's not the case, upload it as a the lower version possible (i.e. POM
> v4), thereby minimizing disruption for other tools scanning central (and
> allow consumption with maven 3.x)
> Longer term:
>   * define a POM v5+ schema (with GAV as attributes, etc...)
> 
> Thoughts ?
ok for new attributes, that can simply added in POM v4.2

not ok for new elements: new elements are POM v5, with all the subtle choices 
to be done that you listed but I still did not have time to properly evaluate, 
and all the people who should really take time to evaluate. Notably those who 
will have to adapt publication rules to Maven Central for POM v5.

Regards,

Hervé

> 
> Guillaume
> 
> [1] https://maven.apache.org/studies/consumer-pom/maven.html
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> 
> Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> 
>  a écrit :
> >  Sorry for chiming in again but perhaps I might have an idea.  The XSD
> > 
> > schema that a POM uses is actually referenced from the POM.  So in essence
> > each POM carries with it what is needed to know to parse it.  Perhaps in
> > Maven 5 (or whichever version) we can require POM parsers to read and use
> > the specific XSD schema referenced in the POM.  That way you can have more
> > room to try changes to the POM format.  But there really should be a
> > mechanism for pushing POM changes downstream and XSD seems like a good
> > option for that.  Sorry if this is already the plan and I'm repeating what
> > is already known.
> > 
> > Hunter
> > 
> > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> > 
> > herve.bout...@free.fr> wrote:
> >  Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > Don't look at Maven code to judge: the whole logic is based on "known
> > > > unknown"
> > > > = we don't know who parses POMs published to Maven Central, but there
> > 
> > are
> > 
> > > > many
> > > > (it's easy to cite many, but not all).
> > > 
> > > I can't buy that argument.  You're saying that we should not assume the
> > 
> > way
> > 
> > > the POM is parsed, but we assume they don't parse arguments.  That's
> > > clearly dodgy, and false for our own parser (both are parsed and
> > > rejected
> > > in strict mode and silently ignored in lenient mode).
> > 
> > I can understand that it does not match the precision of your logic based
> > on
> > 

Re: [VOTE] Release Maven Resolver 1.9.12

[Hervé Boutemy]

+1

notice that Reproducible Builds is NOT ok on 1 file: reference build done on 
*nix with JDK 17 and umask 022

the only issue is in maven-resolver-named-locks-redisson-1.9.12-bundle.zip:
│--rw---  2.0 unx49423 b- defN 23-Jun-16 13:32 objenesis-3.3.jar
│+-rw-r--r--  2.0 unx49423 b- defN 23-Jun-16 13:32 objenesis-3.3.jar
it seems your local repository contains a objenesis-3.3.jar which is not group 
nor world wide readable

Regards,

Hervé

Le vendredi 16 juin 2023, 15:57:43 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> We solved 1 issue:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628
> rsion=12353340
> 
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues
> 
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1962/
> 
> Source release SHA512:
> b24cbd998e1739a89eb693b764fef9f476d53a5b1546ffb87941afcdc9c76bdcd69cbf924782
> ded6067388679446c25c166364cd9ac450e8ef17a70d3f1045ce
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: [DISCUSS] POM model version

[Hervé Boutemy]

Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > Don't look at Maven code to judge: the whole logic is based on "known
> > unknown"
> > = we don't know who parses POMs published to Maven Central, but there are
> > many
> > (it's easy to cite many, but not all).
> 
> I can't buy that argument.  You're saying that we should not assume the way
> the POM is parsed, but we assume they don't parse arguments.  That's
> clearly dodgy, and false for our own parser (both are parsed and rejected
> in strict mode and silently ignored in lenient mode).

I can understand that it does not match the precision of your logic based on 
todays code: did you look at Maven 2 code? did you look at every other 
consumer of Maven Central content?

whatever you feel about it today, that's what has been defined and done for now 
more than 15 years, and proven working, and AFAIK checked when publishing to 
Maven Central

If we change that, we are changing the Maven Central contract for everybody 
from the past and future

Maven 5 is not only about Maven: it's also about Maven Central, which is the 
hardest piece to make sure we don't break usage

Regards,

Hervé



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

Re: [VOTE] Release Maven WAR Plugin version 3.4.0

[Hervé Boutemy]

+1

Reproducible Build ok: reference done with JDK 8 on Windows

Regards,

Hervé

Le dimanche 11 juin 2023, 22:14:08 CEST Michael Osipov a écrit :
> Hi,
> 
> we solved 17 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121
> rsion=12350597
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MWAR/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1955/
> https://repository.apache.org/content/repositories/maven-1955/org/apache/mav
> en/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip
> 
> Source release checksum(s):
> maven-war-plugin-3.4.0-source-release.zip
> sha512:
> ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d0
> 3b3555622f9bad695217ececa078affda6442d76063b5153f998
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version

[Hervé Boutemy]

Le dimanche 11 juin 2023, 23:31:36 CEST Hunter C Payne a écrit :
>  Strange question but maybe it will inspire someone else.  Why does the POM
> the user uses to control the build the exact same format as the POMs
> created to express the results of the build?  Is that necessary?
it has been done in early Maven 2 and Maven Central creation, near 20 years 
ago: why do more complex? And how, when at that time all the concepts had to 
be invented and implemented to simply work first.

> It seems
> to me the discussion is about the drawbacks of that approach.  Perhaps its
> needed for reproducible builds or something but it seems to me those two
> use cases are different and the difficulty comes from trying to make one
> stable format serve both use cases. Hunter
that's why the concepts of build/consumer POM were introduced [1] 5 or 6 years 
ago and the plan about Maven 4 and 5 [2]

with summaries of the history [3] done while working on it

Regards,

Hervé


[1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM

[2] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Core+Roadmap

[3] https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html

> 
> On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau
>  wrote:
>  Le dim. 11 juin 2023 à 22:28, Guillaume Nodet  a écrit :
> > Those are actually two different questions, but I'd like to raise those
> > together, since they do affect the same feature.
> > 
> > 1/ We currently don't have an XML schema for the build POM.  One
> > possibility would be to relax a bit the constraints on the main POM schema
> > (
> > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
> > mandatory in the xml.  By not modifying the validation rules, those
> > elements will have to be present in the object model, so that should be
> > safe.  Another option would be to have a separate schema, but given the
> > small set of changes on the build pom on the current constraints, i
> > think the first solution would be better.  As a reminder, the build pom
> > supports: inferring version for artifacts that are part of the reactor
> > (that's usually done using managedVersion), inferring the relativePath
> > element, ci friendly interpolation for the version.
> 
> +1 to relax
> 
> > 2/ the consumer POM could be streamlined much more using the same
> > techniques than used in the flatten-maven-plugin. Currently, we're only
> > removing the  element, but we could remove the full build
> > section,
> > flatten dependencies, etc...  Packaged artifacts (i.e. with a non pom
> > packaging), can only be used as dependencies, so I think the whole
> > flattening process could make sense.  Is there any drawback in doing so ?
> > Any particular reason the consumer POM support is limited to removing
> > modules and does not go further ?  I can see some discussion in
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> > but
> > those do not seem to be settled.
> 
> Doesnt flattening break transitive dep resolution since depth changes?
> 
> Also drops some build meta which cant be resoled anymore portably like
> compiler setup, which graalvm version was used and lastly would need to
> drop or not props not used elsewhere.
> Think staying as close as possible of the source is overall good to consume
> as intended (build control) until the transformer is fully configurable
> (never hopefully since it sounds overcomplicated).
> 
> > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet  a écrit :
> > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy  a
> > > 
> > > écrit :
> > >> adding a new POM element in build POM was supposed to be something for
> > >> Maven 5
> > >> and to trigger a POM 5 version, to make clear that we are leaving the
> > >> Maven 3
> > >> space (that uses POM version 4, hence the need for version
> > >> clarification
> > >> between Maven and it POM model version)
> > >> 
> > >> if we enter that space before having released Maven 4, we're adding
> > >> more
> > >> complexity: do you really want to work on Maven 5 now?
> > >> 
> > >> 
> > >> another aspect:
> > >> do we want to have this new improvement only for Maven 4/5 or also have
> > >> it for
> > >> Maven 3.9?
> > >> in Maven 3.9, such little enhancement were implemented as XML
> > >> attributes
> > > 
> > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with
> > > 3.9.x, I end up with the following diff
> > > ht

Re: [VOTE] Release Apache ASF parent 30

[Hervé Boutemy]

wow, what a release!

+1

Reproducible build ok

Regards,

Hervé

Le dimanche 11 juin 2023, 19:02:05 CEST Slawomir Jaranowski a écrit :
> Hi,
> 
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250
> rsion=12352680
> 
> Commits:
> https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1035/
> https://repository.apache.org/content/repositories/orgapacheapache-1035/org/
> apache/apache/30/apache-30-source-release.zip
> 
> Source release checksum(s):
> apache-30-source-release.zip - SHA-512 :
> 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc
> 033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7
> 
> Staging site:
> https://maven.apache.org/pom-archives/asf-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: [DISCUSS] POM model version

[Hervé Boutemy]

Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit :
> Le ven. 9 juin 2023 à 08:59, Hervé Boutemy  a écrit :
> > adding a new POM element in build POM was supposed to be something for
> > Maven 5
> > and to trigger a POM 5 version, to make clear that we are leaving the
> > Maven 3
> > space (that uses POM version 4, hence the need for version clarification
> > between Maven and it POM model version)
> > 
> > if we enter that space before having released Maven 4, we're adding more
> > complexity: do you really want to work on Maven 5 now?
> > 
> > 
> > another aspect:
> > do we want to have this new improvement only for Maven 4/5 or also have it
> > for
> > Maven 3.9?
> > in Maven 3.9, such little enhancement were implemented as XML attributes
> 
> Fwiw, if I reduce the diff between the XSD generated with 3.0 and with
> 3.9.x, I end up with the following diff
> https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b
> So, you're right, no new elements have been introduced. A few attributes
> added, one element removed.
yes, it's a real strategy that has been defined a very long time ago, as a 
strong promise from Maven project to Maven Central consumers

> However I really don't understand how adding an attribute vs an element
> makes the POM more compatible. Our own generated parser will reject any
> unknown new attribute the same way as an unknown element (that's for any
> maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a POM
> with an element that has been introduced later:
> https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0
> So I'm not really buying the argument about attribute / element at this
> point.  If that could be clarified, it would be nice !
the idea is that Maven 1, 2 and 3 before 3.6.0 (MNG-6059) defined elements 
only, not attributes, then people parsing POMs look at elements, not 
attributes: adding attributes won't break external parsers.

Don't look at Maven code to judge: the whole logic is based on "known unknown" 
= we don't know who parses POMs published to Maven Central, but there are many 
(it's easy to cite many, but not all).

> So I think the question comes down to: do we prefer modifying/overwriting
> the schema as we did in the past or do we prefer cleanly versioning it.  In
> both cases, I think we need to keep it compatible, i.e. only add
> elements/attributes.  The first option is much easier to implement: just do
> nothing as we did in the past, but this has the drawback of not giving
> people/tools much warning or information about possible changes.  We simply
> overwrite the schema from the web site with the latest one at each release,
> hoping that tools will not see the change and that they don't really cache
> the schema (in case you really need the latest). The other option is to
> more properly version the schema.  This would need additional code if we
> want to correctly detect which version is the lower version needed to
> correctly write a given POM.  But even for doc changes, I think it may be
> preferable to micro version the schemas.
the strategy on adding new elements has always been yet to define precisely, 
and called Maven 5
If you want to work on details of Maven 5 way to add new elements, it has to 
be worked seriously (xmlns? xsd?), documented, tested widely, ...

> The scm.child.xxx attributes that were added are not meaningful for the
> consumer afaik: they are used for build time and for doc, when you use an
> artifact as a dependency (i.e. on the consumer side), those attributes
> won't be used.  So from a consumer POV, they don't carry any semantics and
> can safely be silently discarded.  This is also the case for this new
> priority attribute, as it only affects the current project or child
> projects.  In that sense this new feature could just be silently added to
> the schema as previous things, so I'm fine with not versioning the schema
> now if that's the consensus.
I would not say consumers never use scm.child.xxx attributes, but yes, not for 
the core dependency aspects: if we accepted to take the risk on these 
attributes, it's exactly for that reason
And yes, to me, that would be the same for plugin execution priority: not used 
by dependency consumers

> 
> The problem (and that's really something we need to fix), is that we don't
> any real difference between the build POM and the consumer POM schemas.  We
> also don't make a real difference between consuming as a bom / dependency /
> plugin, and consuming as a parent.  Both cases are really different, as the
> first one could strip out most of the  section.  One possibility
> would be to more formerly identify those 3 use cases (build on file system,
> consuming as a dependency and consuming 

Re: [DISCUSS] POM model version

[Hervé Boutemy]

adding a new POM element in build POM was supposed to be something for Maven 5
and to trigger a POM 5 version, to make clear that we are leaving the Maven 3 
space (that uses POM version 4, hence the need for version clarification 
between Maven and it POM model version)

if we enter that space before having released Maven 4, we're adding more 
complexity: do you really want to work on Maven 5 now?


another aspect:
do we want to have this new improvement only for Maven 4/5 or also have it for 
Maven 3.9?
in Maven 3.9, such little enhancement were implemented as XML attributes


and of course, independently from this XML mapping and version details, there 
is the question to be seriously discussed about the feature itself: is this 
opportunity of introducing the "priority" field something we want (that reuses 
an implementation that is de-facto already existing internally for a long 
time, it just exposes it)

Regards,

Hervé


Le jeudi 8 juin 2023, 22:56:27 CEST Guillaume Nodet a écrit :
> While working on an issue [1], I've raised a PR [2] which is adding an xml
> element to the POM.  So I raised the model version to 4.2.0.  My
> understanding is that the build/consumer POM feature [3] was created so
> that we could keep compatibility.  This is clearly indicated in the wiki
> page:  "Maven is stuck on POM v4 for a long time now, because changing the
> POM version and publishing artifacts on Maven Central with this new model
> would break consumers using either older Maven versions or other build
> tools (that use POM v4 as a compatibility format)."
> 
> However, I think this axiom is false.  What happens, is that all maven
> versions are perfectly capable of consuming any model when used as a BOM /
> dependency / plugin, as the parser simply ignores any unknown attribute or
> element.  I can install a jar with the 4.2.0 model and consume it with any
> 3.x version without any problem.  The only issue is when using that project
> as a parent, in which case, the validation is strict and fails with the
> 4.2.0 model.
> 
> So, saying that "new model would break consumers using [...] older Maven
> versions" is just wrong, as they work perfectly when consuming the POM as
> dependencies.  I can create a small git repo if you want to experiment, but
> that has been first checked by @cstamas, then double checked by myself.
> 
> Now, the discussion is whether we want to allow modifications to the POM
> model and support new versions of it.  I think this would be quite safe,
> provided that there's no incompatible changes, i.e. it's only adding new
> elements/attributes.
> I don't think this goes against the build/consumer feature, as I think the
> main benefit of this feature is to allow default values using sane
> conventions (mainly the project layout on the file system, which is not
> available anymore in the remote repository, so this data has to be present
> for consumers).
> 
> So, the question: should we go ahead and allow introducing newer POM models
> to bring in a few features that have been delayed for a long time because
> the assumption was that the model could never change ?  One possibility to
> minimize the disruption would be to have a smart POM writer : i.e. it could
> transform the POM to a 4.0.0 model if no new features are actually used, so
> that only projects actually using the newly introduced features would
> actually use the 4.x pom version.
> 
> Guillaume
> 
> [1] https://issues.apache.org/jira/browse/MNG-7804
> [2] https://github.com/apache/maven/pull/1147
> [3] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM





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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

Le mardi 6 juin 2023, 20:19:23 CEST Guillaume Nodet a écrit :
> One question for people that want JDK 8 support.  What IDE do they use to
> develop ? Because none of the actual IDE is running JDK 8, though they can
> be used by JDK 8, just like maven with toolchains.
good point, thanks for adding that one

> So really, the argument does not really stand, but for the very minority of
> devs still using emacs/vim.
> It really comes down to ease of use (i.e. not having to use --release flag
> or to setup a toolchain) vs staying on JDK for 10 more years.
yes, working on toolchains ease of use is to me a good way to prepare for the 
move

and as I said also plugin prerequisites history is another

I recently saw https://issues.apache.org/jira/browse/MNG-7566 that I 
overlooked: I think that this improvement deserves being backported to Maven 
3.9

everything that will help users not able to upgrade better know how to deal 
with their setup is necessary to have the upgrade for the most up to date not 
kill our old installed base

with the current discussion and the different solutions identified, I may start 
to be convinced the move may become reasonable



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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

requirements history column has just been added to dist tool report:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

on 52 plugins we maintain, 3 have published prerequisites history to help users 
know what version to use when latest has too modern prerequisites

for people interested in helping us, you can see how to provide us a PR by 
looking at issues linked from https://issues.apache.org/jira/browse/MPLUGIN-400

PLEASE HELP US

Regards,

Hervé

Le mardi 6 juin 2023, 09:30:39 CEST Romain Manni-Bucau a écrit :
> @Hervé: was not really my point, more than forcing the maven version as
> plugins do also forces the java version so as soon as we decide for maven
> plugins are good. They can be compiled with java 8 and run on maven 3+4
> while API is stable or just maven 4 if not. For external plugins some are
> already compiled with java 11 only so will not run on java 8 builds even if
> 3.9 supports it so think this part is really good technically - agree with
> you in terms of doc we can be better but requires a lot of time and effort
> as you mentionned.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> Le mar. 6 juin 2023 à 09:11, Hervé Boutemy  a écrit :
> > you're right that we're currently talking about core, not plugins
> > 
> > but this question will inevitably extend from core to plugins, and there
> > are
> > much more plugin developers than core developers
> > 
> > then I think that getting a large view is useful
> > 
> > and honestly, now that I had the opportunity to do the summary and find
> > dist-
> > tool + DOCCK-38 improvements, I know how to continue to prepare the future
> > of
> > this JDK prerequisite question on plugins
> > 
> > I'll just need that people interested in upgrading JDK prerequisite help
> > doing
> > the hard documentation work required to make that move in a smooth way =
> > avoid
> > the "I only care about users who can use latest JDK" effect
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> > > Do we really care about plugins Hervé? They are compatible with some
> > 
> > maven
> > 
> > > versions so cover the underlying prerequisites, no?
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > 
> > https://github.com/rmannibucau>
> > 
> > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > 
> > > <
> > 
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> > 
> > > Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a
> > 
> > écrit :
> > > > > > notice that this will also impact all plugins: and given the few
> > 
> > work
> > 
> > > > done
> > > > 
> > > > > > on
> > > > > > plugins to clearly show what plugin version remains compatible
> > 
> > with a
> > 
> > > > JDK
> > > > 
> > > > > > release, I feel we're not taking the topic the right way
> > > > > 
> > > > > Can you detail it please? While we keep plugin-api java 8 compat -
> > 
> > which
> > 
> > > > is
> > > > 
> > > > > not under discussion there - there is no more impact than today
> > > > > normally.
> > > > 
> > > > currently, if you are still using JDK 7 or even earlier (not a shame,
> > 
> > just
> > 
> > > > a necessity), it's easy to select latest compatible Maven release:
> > > > https://maven.apache.org/docs/history.html
> > > > 
> > > > What about using latest compatible plugins?
> > > > It's where finding documentation starts to become hard:
> > > > 
> > > > - each plugin has it public documentation showing only the latest JDK
> > > > prerequisite
> > 
> > > > - our consolidated view itself is just known from experts only:
> >

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

you're right that we're currently talking about core, not plugins

but this question will inevitably extend from core to plugins, and there are 
much more plugin developers than core developers

then I think that getting a large view is useful

and honestly, now that I had the opportunity to do the summary and find dist-
tool + DOCCK-38 improvements, I know how to continue to prepare the future of 
this JDK prerequisite question on plugins

I'll just need that people interested in upgrading JDK prerequisite help doing 
the hard documentation work required to make that move in a smooth way = avoid 
the "I only care about users who can use latest JDK" effect

Regards,

Hervé

Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> Do we really care about plugins Hervé? They are compatible with some maven
> versions so cover the underlying prerequisites, no?
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a écrit :
> > > > notice that this will also impact all plugins: and given the few work
> > 
> > done
> > 
> > > > on
> > > > plugins to clearly show what plugin version remains compatible with a
> > 
> > JDK
> > 
> > > > release, I feel we're not taking the topic the right way
> > > 
> > > Can you detail it please? While we keep plugin-api java 8 compat - which
> > 
> > is
> > 
> > > not under discussion there - there is no more impact than today
> > > normally.
> > 
> > currently, if you are still using JDK 7 or even earlier (not a shame, just
> > a necessity), it's easy to select latest compatible Maven release:
> > https://maven.apache.org/docs/history.html
> > 
> > What about using latest compatible plugins?
> > It's where finding documentation starts to become hard:
> > 
> > - each plugin has it public documentation showing only the latest JDK
> > prerequisite
> > 
> > - our consolidated view itself is just known from experts only:
> > 
> > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > b/master/site/dist-tool-prerequisites.html
> > 
> > 
> > we added some time ago "System Requirements History" for that purpose =
> > https://issues.apache.org/jira/browse/MPLUGIN-400
> > for example, once a plugin has documented its history, you get:
> > 
> > https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.ht
> > ml#system-requirements
> > 
> > Every plugin should document its system requirements history
> > = we need to organise the work to make sure it's done in our own plugins:
> > I did the job on a few ones, but it has to be generalised and I don't see
> > anybody interested in doing the work (and I'm tired of doing myself the
> > documentation cleanup on many aspects...)
> > 
> > notice: now that I wrote that summary, I see we can:
> > 1. add a check in dist-tool prerequisites report, to have a clear global
> > view
> > 2. add a check in DOCCK Maven Documentation Checker Plugin: it did not
> > have any release for years, this will be a good reason to update it
> > https://maven.apache.org/plugins/maven-docck-plugin/index.html
> > https://issues.apache.org/jira/browse/MDOCCK-38 created
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

> > notice that this will also impact all plugins: and given the few work done
> > on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> 
> Can you detail it please? While we keep plugin-api java 8 compat - which is
> not under discussion there - there is no more impact than today normally.

currently, if you are still using JDK 7 or even earlier (not a shame, just a 
necessity), it's easy to select latest compatible Maven release:
https://maven.apache.org/docs/history.html

What about using latest compatible plugins?
It's where finding documentation starts to become hard:

- each plugin has it public documentation showing only the latest JDK 
prerequisite

- our consolidated view itself is just known from experts only:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html


we added some time ago "System Requirements History" for that purpose = 
https://issues.apache.org/jira/browse/MPLUGIN-400
for example, once a plugin has documented its history, you get:
https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html#system-requirements

Every plugin should document its system requirements history
= we need to organise the work to make sure it's done in our own plugins: I did 
the job on a few ones, but it has to be generalised and I don't see anybody 
interested in doing the work (and I'm tired of doing myself the documentation 
cleanup on many aspects...)

notice: now that I wrote that summary, I see we can:
1. add a check in dist-tool prerequisites report, to have a clear global view
2. add a check in DOCCK Maven Documentation Checker Plugin: it did not have any 
release for years, this will be a good reason to update it
https://maven.apache.org/plugins/maven-docck-plugin/index.html
https://issues.apache.org/jira/browse/MDOCCK-38 created

Regards,

Hervé




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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

Le mardi 6 juin 2023, 01:54:27 CEST Henning Schmiedehausen a écrit :
> To get this discussion a bit more back to actual substance:
> 
> Do you still need toolchains with JDK 11/17? I set the release version to
> "8" (or anything else) in my builds, ripped out all the toolchains and it
> "just works". We have done this for Jdbi for ages (require Java 11+ as the
> build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
> bytecode. So far, we had zero complaints from users that the resulting
> releases do not work / cause problems on JDK 8.
> 
> It seems to me that toolchains are only relevant if you need to compile to
> Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
> release target.
> 
> Am I missing something?
Yes: you are perfectly describing compiling
the missed part is unit-tests and *-tests execution = when they target Java 8 
bytecode, people want to execute tests against JDK 8

Regards,

Hervé



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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Hervé Boutemy]

I think this difference during Maven build between compile time JDK vs tests 
execution time JDK is key for normal users choice. And ease of setup if 
multiple JDKs are involved (= it's not easy to have configured prerequisites in 
place)

I suppose good articles showing the full setup to do so would perhaps help 
normal users to learn how to do such a nice setup: knowledge on the many 
pieces to do this is not well known

something like a good Baeldung article?

and with something like the Toolchains improvements to more easily deploy 
prerequisites, perhaps this could fly

Regards,

Hervé

Le jeudi 1 juin 2023, 18:51:20 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> define 3 Java versions in my toolchains.xml, and then add 3 executions for
> surefire like here?
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.
> html
> 
> Thanks
> T
> 
> On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory  wrote:
> > I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which
> > usually is the longest and most resource intensive part of a build.
> > 
> > How would you do that were it not for a GitHub matrix?
> > 
> > Gary
> > 
> > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák  wrote:
> > > Howdy,
> > > 
> > > From recent discussions I see an interesting pattern: it seems that
> > 
> > people
> > 
> > > (even our PMCs) are using Maven in a way that is making sure that "same
> > > Java version" (I guess vendor + version) is used from "beginning" to
> > 
> > "end".
> > 
> > > And "beginning" here means BUILDING (think workstations and CI and so
> > 
> > on),
> > 
> > > while "end" means PRODUCTION (deploying the stuff into production).
> > > 
> > > Why is that?
> > > 
> > > We all know that even before this "speedup" of Java releases (so to say,
> > 
> > up
> > 
> > > to Java 8) we did put extra effort into supporting this (running Maven
> > > on
> > > different Java versions and producing another bytecode output). One can:
> > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > 
> > older)
> > 
> > > - use release compiler flag (if Java9+ used)
> > > - use toolchains
> > > 
> > > Why does any of these above "does not work" for those "aligning Java
> > > from
> > > beginning to end"?
> > > 
> > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > 
> > knows
> > 
> > > what) it is REALLY HARD to miss the automation of getting JDKs and tools
> > > (and keeping them up to date!!!) on workstations and CIs (deployment not
> > > counted here, but hopefully it is automated as well).
> > > 
> > > Another point is that upcoming Maven 4 has tremendous improvements
> > > targeting toolchains.
> > > 
> > > Finally, a bit of digression, but very much related thing: as Niels
> > > showcased on other thread in
> > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > > 
> > > The CI "matrix" build's Java version part can be moved into Maven
> > > itself.
> > > Personally, I always hated "matrix" as they explode very easily (size
> > 
> > wise)
> > 
> > > but in MOST cases they really just "warm the oceans" (from HB) and do
> > > not
> > > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > > rebuild the same commit over and over with Java8, Java11, Java17 only to
> > > "be sure" it will work, is really an overkill (and very wasteful). The
> > > added beauty of applying this pattern is that one can perform the whole
> > > build and testing (using different Javas) even on their own
> > > workstations.
> > > 
> > > Does Maven miss some features (aside from those above) to make it
> > 
> > possible
> > 
> > > for those "aligning" Java versions to move?
> > > 
> > > Thanks
> > > T





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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

it's not about *one not wanting* to upgrade (anybody can use JDK 17 if they 
want currently)

it's about *one forcing everybody else* to upgrade (and enter the toolchain 
setup question)


I'd be curious to see what will happen the day one of the base plugin force to 
upgrade:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

Regards,

Hervé

Le mardi 19 juillet 2022, 21:28:07 CEST Delany a écrit :
> Elliotte, you make it sound like they don't *want* to upgrade to JDK17. But
> who wouldn't want that?
> Its usually the business holding that back. If I can tell the business,
> sorry, but Maven requires it - then that's the end of the conversation.
> They won't argue. Switching to another build system to avoid doing the
> inevitable is just making more work.
> 
> What little I know, I appreciate the bold move to JDK17 and I guess it'll
> pay off in the long run. Who knows what's next around the corner.
> 
> Regards,
> Delany
> 
> On Tue, 19 Jul 2022 at 20:39, Elliotte Rusty Harold 
> 
> wrote:
> > On Tue, Jul 19, 2022 at 12:25 PM Karl Heinz Marbaise 
> > 
> > wrote:
> > > Hi to all,
> > > 
> > > what do you think about using JDK17 as minimum requirement for running
> > > the future Apache Maven 4.0.0 ?
> > 
> > Bluntly, its an atrocious idea that work would likely lead to forks of
> > maven or a lot of projects abandoning it for other build systems, as well
> > as many more never upgrading.
> > 
> > Developer preference does not outweigh the needs of the massive installed
> > base.
> > 
> > > Kind regards
> > > Karl Heinz Marbaise
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Elliotte Rusty Harold
> > elh...@ibiblio.org





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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

+1

I really don't what benefit we get from going to Java 17

I perfectly see the impact we'll have on our users: for what benefit?

notice that this will also impact all plugins: and given the few work done on 
plugins to clearly show what plugin version remains compatible with a JDK 
release, I feel we're not taking the topic the right way

Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
>  I'm not sure I would worry too much about that David.  I think most devs
> who want better syntax moved from Java sometime ago.  They might still be
> on the JVM just not writing Java.  Also, Maven is a mature project.  I
> don't think devs considering contributing to it are thinking about using
> the latest and greatest version of Java.  Compatibility is probably a
> bigger concern for the user base.  Just my opinion.
> 
> Hunter
> On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
>  wrote:
> 
>  I wonder if having maven require java 8 syntax discourages any potential
> contributors who are used to coding using more recent developments. I have
> no idea how to tell, but maybe someone else does.
> 
> David Jencks
> 
> > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise  wrote:
> > 
> > Hi,
> > 
> > my clear opinion is to go  with most recent JDK LTS version for the
> > release point of Maven 4.0.0 which I assume will be JDK 21...
> > 
> > That means clear the build time requirement which is completely
> > different from runtime of an application.
> > 
> > 
> > Older JDK's are supported by some vendors by having particular special
> > support which most of the time requires special contracts (means also
> > paying money for it)..some of them offering builds without paying money
> > yes..
> > 
> > Older runtime target are supported with different approaches like
> > Toolchain or via `--release XX` which exists since JDK9+.
> > 
> > 
> > Furthermore if someone is not capable of upgrading the build environment
> > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
> > 
> > If it would be requirement to port things back to 3.8.X or 3.9.X it
> > could be handled by someone who has the time etc. to do that ... if not,
> > those people might think of paying someone to do that work...
> > 
> > 
> > The given argument about JPMS for migration causes issues is from my
> > point of view false-positive because migration to newer JDK versions
> > does not require JPMS usage...
> > 
> > Even platforms like AWS support JDK17 in the meantime which is the
> > runtime...
> > 
> > 
> > Based on the argument we don't need  features of JDK17+ I see a number
> > of things which could make our handling/maintenance easier for example
> > using sealed classes to prevent exposing internal things to public which
> > could be used etc. also some other small features (`var` for example;
> > Text-Blocks in Tests etc) or using records in some situation...
> > 
> > 
> > Based on the maintenance part it would mean in consequence to downgrade
> > to even JDK7... (or even lower) because you can get support for older
> > JDK version in some ways... (JDK7 from azul for example)
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: GH issues and GH discussions

[Hervé Boutemy]

Le lundi 29 mai 2023, 13:50:58 CEST Karl Heinz Marbaise a écrit :
> To fulfill the formalism (also have documented the decision here on the
> ML) we should start simply a VOTE to get an in general decision about
> moving to GH-issues to leave JIRA behind... (not about the details) that
> can be done later on...(for example using GH discussions etc.)
> 
> afterwards we can decide with which project we would like to start and
> fiddle the details.

I'd do it the exact opposite order:
- test first Jira to GH  for a few projects
- clarify Users ML replacement with GH Discussion (IIUC, this is what the GH 
discussion looks like, but I did not yet understand fuly: i have no 
experience, sharing examples would be useful)

and only once we found the right way to do one or the other, vote for making 
the real move



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

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4

[Hervé Boutemy]

+1

Reproducible Builds ok: reference build done with JDK 8 on Windows

Regards,

Hervé

Le vendredi 26 mai 2023, 21:29:11 CEST Michael Osipov a écrit :
> Hi,
> 
> we solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821
> rsion=12353222
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1948/
> https://repository.apache.org/content/repositories/maven-1948/org/apache/mav
> en/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-report
> s-plugin-3.4.4-source-release.zip
> 
> Source release checksum(s):
> maven-project-info-reports-plugin-3.4.4-source-release.zip
> sha512:
> c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484
> ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-> 
> LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: GH issues and GH discussions

[Hervé Boutemy]

Le vendredi 26 mai 2023, 19:41:53 CEST Benjamin Marwell a écrit :
> Big +1, as more and more projects are already migrating (including Apache
> Shiro).
> 
> I'd vote for maven-jlink-plugin: Not many issues currently.
> 
> > not having to create an issue if a PR exists first
> 
> I'd at least make milestones mandatory in that case.
AFAIK, GH Milestones are useful when you want to assign an issue that is not 
yet fixed
see for example https://github.com/apache/maven-mvnd/milestones

But it does not seem absolutely necessary, since GH Release Notes will get the 
release content once the issue is fixed
example: https://github.com/apache/maven-mvnd/releases

We'll need to define which GH Labels are available, and how the release notes 
drafter use it to have better release notes
https://github.com/apache/maven-mvnd/labels

> It is far less work than maintaining an issue.
> 
> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy :
> > Hi,
> > This has been already discussed in the past.
> > But due to recent changes in ASF Jira infrastructure (limitation of
> > Jira users, validation of account creation).
> > Maybe we could reconsider moving from Jira to GH issues and why not
> > simplify the workflow as well.
> > I imagine not having to create an issue if a PR exists first (sounds
> > like duplicate work).
> > By the way, release notes will be automatically created from PRs.
> > (could be manually modified if a change doesn't have a PR).
> > 
> > Regarding migration, we can start project by project.
> > Few options:
> > - extreme simplicity, do not migrate any data (just mark the Jira
> > project as read only with a banner/link to corresponding gh issues).
> > If someone really needs an issue to get fixed he will clone it to GH
> > - middle complexity, migrate only open issues (components moved as a
> > label)
> > - extreme complexity, migrate all issues of a project (components
> > moved as a label and version created)
> > 
> > We can start by small projects such as cache-extension and one plugin
> > (compiler?)
> > 
> > Regarding GH discussions, maybe we can open discussions for
> > https://github.com/apache/maven which sounds like a natural place for
> > users to go. (discussions could be mirrored to a ML)
> > I do not have a strong opinion here, but I feel like opening
> > discussions for every single repo will be complicated to follow up.
> > 
> > WDYT?
> > 
> > cheers
> > Olivier
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: GH issues and GH discussions

[Hervé Boutemy]

on testing GH issues migration from Jira: yes

cache-extension [1] looks like an interesting example, given it has a small 
history with its Jira content
we also have mvnd which uses GH issues from the start: testing and making 
clear practices on release and release notes could also be worked there [2]

we'll need to write down what practical steps such a migration requires
=> probably a good fit for our Wiki, where we already organized equivalent 
updates in the past [3]

on using GH discussions, I suppose this should be an independent next 
discussion


[1] https://github.com/apache/maven-build-cache-extension

[2] https://github.com/apache/maven-mvnd

[3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure

Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> Hi,
> This has been already discussed in the past.
> But due to recent changes in ASF Jira infrastructure (limitation of
> Jira users, validation of account creation).
> Maybe we could reconsider moving from Jira to GH issues and why not
> simplify the workflow as well.
> I imagine not having to create an issue if a PR exists first (sounds
> like duplicate work).
> By the way, release notes will be automatically created from PRs.
> (could be manually modified if a change doesn't have a PR).
> 
> Regarding migration, we can start project by project.
> Few options:
> - extreme simplicity, do not migrate any data (just mark the Jira
> project as read only with a banner/link to corresponding gh issues).
> If someone really needs an issue to get fixed he will clone it to GH
> - middle complexity, migrate only open issues (components moved as a label)
> - extreme complexity, migrate all issues of a project (components
> moved as a label and version created)
> 
> We can start by small projects such as cache-extension and one plugin
> (compiler?)
> 
> Regarding GH discussions, maybe we can open discussions for
> https://github.com/apache/maven which sounds like a natural place for
> users to go. (discussions could be mirrored to a ML)
> I do not have a strong opinion here, but I feel like opening
> discussions for every single repo will be complicated to follow up.
> 
> WDYT?
> 
> cheers
> Olivier
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Maven SCM 2.0.1

[Hervé Boutemy]

+1

Reproducible Build ok: reference build done with JDK 17 on *nix

Regards,

Hervé

Le lundi 15 mai 2023, 20:55:39 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> We solved 2 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828
> rsion=12353247
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/SCM/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1944
> 
> Source release checksum(s) SHA512:
> d4aa06f30c6fff89e427a144f98b18acd57fcdee1abe72454920b70d3131e280bb0276266bf6
> 727f0e5f42dfde126693d3ab1e132ec58b440839e1c3f394c415
> 
> Staging site:
> https://maven.apache.org/scm-archives/scm-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

[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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven GPG Plugin version 3.1.0

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Slawomir Jaranowski, Tamás Cservenák, Michael Osipov, Jean-Baptiste 
Onofré, Olivier Lamy, Hervé Boutemy

PMC quorum reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.





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

[VOTE] Release Apache Maven GPG Plugin version 3.1.0

[Hervé Boutemy]

Hi,

We solved N issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521=12350161=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1935
https://repository.apache.org/content/repositories/maven-1935/org/apache/maven/plugins/maven-gpg-plugin/3.1.0/maven-gpg-plugin-3.1.0-source-release.zip

Source release checksum(s):
maven-gpg-plugin-3.1.0-source-release.zip sha512: 
9cd0cb2df374b1db58873b8f5011cc785310a43d3fb4cb43dbbd3501a37f0bd0fffa14aa61a3b29b2b770dc7e2e57b7f9ebac6eb7383f400645322fc6352a08c

Staging site:
https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] Release Apache Resource Bundles 1.5

[Hervé Boutemy]

Le samedi 1 avril 2023, 23:31:39 CEST Slawomir Jaranowski a écrit :
> Hi
> 
> There is also open staging - orgapacheapache-1033 in nexus.
deleted: I probably did another deploy when building and deploying site...

> 
> Tests on jenkins are filed:
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-apache-resourc
> es/job/master/
newest builds are fine, no worries

> 
> Locally test - org.apache.its.IT_ZipAndTarCreation failed with:
> 
> ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single
> (source-release-assembly) on project zip-and-tar: Execution
> source-release-assembly of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed: group id
> '1262638422' is too big ( > 2097151 ). Use STAR or POSIX extensions to
> overcome this limit -> [Help 1]
> 
> Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Java version: 11.0.18, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@11/11.0.18/libexec/openjdk.jdk/Contents/Home
> OS name: "mac os x", version: "12.6.3", arch: "x86_64", family: "mac"
uh, it's the first time I see this
I'll try to investigate later, but I'm not worried for this release: this 
issue is not about the current content but probably an issue that pre-existed 
when run on Mac

> 
> sob., 1 kwi 2023 o 19:56 Hervé Boutemy  napisał(a):
> > Hi,
> > 
> > We solved 14 issues:
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314621;
> > version=12352992=Text
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheapache-1032/
> > 
> > https://repository.apache.org/content/repositories/orgapacheapache-1032/or
> > g/apache/apache/resources/apache-resource-bundles/1.5/apache-resource-bund
> > les-1.5-source-release.zip
> > 
> > Source release checksum(s):
> > apache-resource-bundles-1.5-source-release.zip.sha512:
> > ba10e36f8f20b54676b78a1fb5ff20f570f18daa6fe314e7372824ecda72f4c94c85d5c172
> > b79716cc9b79ef4a65b06dbd5f7e83305e4aac0734fa351f3691f1
> > 
> > Staging site:
> > 
> > https://maven.apache.org/apache-resource-bundles-archives/apache-resource-> 
> > > bundles-LATEST/
> > 
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for at least 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

[VOTE] Release Apache Resource Bundles 1.5

[Hervé Boutemy]

Hi,

We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314621=12352992=Text

Staging repo:
https://repository.apache.org/content/repositories/orgapacheapache-1032/
https://repository.apache.org/content/repositories/orgapacheapache-1032/org/apache/apache/resources/apache-resource-bundles/1.5/apache-resource-bundles-1.5-source-release.zip

Source release checksum(s):
apache-resource-bundles-1.5-source-release.zip.sha512: 
ba10e36f8f20b54676b78a1fb5ff20f570f18daa6fe314e7372824ecda72f4c94c85d5c172b79716cc9b79ef4a65b06dbd5f7e83305e4aac0734fa351f3691f1

Staging site:
https://maven.apache.org/apache-resource-bundles-archives/apache-resource-bundles-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1




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

Re: [VOTE] Release Maven SCM Publish Plugin version 3.2.1

[Hervé Boutemy]

+1

Reproducible Build ok: reference build done with JDK 8 on Windows

Regards,

Hervé

Le dimanche 26 mars 2023, 19:51:31 CEST Michael Osipov a écrit :
> Hi,
> 
> We solved 8 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317920
> rsion=12349526
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MSCMPUB/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1904/
> https://repository.apache.org/content/repositories/maven-1904/org/apache/mav
> en/plugins/maven-scm-publish-plugin/3.2.1/maven-scm-publish-plugin-3.2.1-sou
> rce-release.zip
> 
> Source release checksum(s):
> maven-scm-publish-plugin-3.2.1-source-release.zip
> sha512:
> 0ccb7d851b9774de6a82302f95a3da5a551eea695afe3160c6125d50f72b70abea57476f8952
> 2d400203be04a8dba14e3ade2029ed5524fe851a0f233b862f82
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-scm-publish-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Migrating Apache Resource Bundles from svn to Git

[Hervé Boutemy]

migration done:

source: https://github.com/apache/maven-apache-resources

SNAPSHOT site 
https://maven.apache.org/apache-resource-bundles-archives/apache-resource-bundles-LATEST/

once the 1.5 release will be done, we can replace the old page 
https://maven.apache.org/apache-resource-bundles/

Le jeudi 9 mars 2023, 08:10:28 CET Hervé Boutemy a écrit :
> this is one of the last piece of code that the Maven project maintains in
> svn (de-facto not doing any release...)
> This is not a funny task, but it has to be done
> 
> I finally prepared the work, with a plan fully described in Jira
>   https://issues.apache.org/jira/browse/MASFRES-20
> 
> and a draft svn 2 git clone available in a temporary space before I create
> the proposed definitive
> https://github.com/apache/maven-apache-resources.git repository
> 
> If nobody objects, I'll finish the work this week-end
> 
> Regards,
> 
> Hervé
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [DISCUSS] m-remote-resources-p

[Hervé Boutemy]

for the aggregate aspect

our Apache Parent POM (provided by Maven project to the whole ASF projects) 
does use this process goal:
https://github.com/apache/maven-apache-parent/blob/6b850c5f263c9bb4074ebb9a7974344059dd834c/pom.xml#L317

and the aggregation aspect has exactly be done for the 
apache-jar-resource-bundle, for DEPENDENCIES.vm:
https://github.com/apache/maven-apache-resources/tree/master/apache-jar-resource-bundle/src/main/resources/META-INF

ASF parent POM still uses 1.7.0
https://github.com/apache/maven-apache-parent/blob/6b850c5f263c9bb4074ebb9a7974344059dd834c/pom.xml#L260

One day, we'll need to upgrade this POM according to the change: no hurry, but 
at least it is our ASF own dogfood

For other users of this goal, I don't know: IIUC, a good part of the work on 
m-remote-resources-p started from users complaining about 3.0.0 regressions, 
then I suppose these are from people not only using ASF parent POM
It would be nice to hear from them

Regards,

Hervé

Le jeudi 9 mars 2023, 15:43:51 CET Tamás Cservenák a écrit :
> Howdy,
> 
> I would like to share (and possibly exchange) some recollections about the
> m-remote-resource-p.
> 
> For start, there is an ongoing PR to drop all the accumulated legacy stuff:
> https://github.com/apache/maven-remote-resources-plugin/pull/26
> 
> But what caught my eye are these lines:
> https://github.com/apache/maven-remote-resources-plugin/blame/e7cc40df2f5ee9
> 9cde90d1dc7308df719f1c1963/src/main/java/org/apache/maven/plugin/resources/r
> emote/ProcessRemoteResourcesMojo.java#L134-L138
> 
> In short, what this plugin does is (should be) nearly trivial: collect
> project, project dependencies, resolve some resource bundles, apply
> Velocity templates, done.
> 
> BUT, due to the comment and removal of `requiresDependencyResolution` this
> plugin does what Maven should be doing: resolves/collects and builds
> transitive deps. And I feel this is wrong.
> 
> As you see in comment, the REASON of removal (and hence bloating the Mojo
> with all-the-stuff-that-Maven-should-do) was to implement
> https://issues.apache.org/jira/browse/MRRESOURCES-41 that again looks like
> some 'wish" issue, with idea "to mimic the assembly plugin's
> runOnlyAtExecutionRoot flag". Also, to me this "smells" like aggregation
> without aggregator (and resolution without Maven) -- so just a WTH moment
> one after another.
> 
> I find this wrong, as it sacrifices simplicity and reusability (plugin must
> do what Maven already does for plugin, if asked for), and it resulted in
> this plugin to become bloat, and later totally neglected and full of
> booby-traps.
> 
> So, my proposal is like in PR:
> 
> 1. return this Mojo switch `requiresDependencyResolution=TEST` and let Mojo
> filter as it needs. This is already done in PR and big chunk of code is
> gone, all tests except the one IT that tests the runOnlyAtExecutionRoot
> passes OK.
> 2. above implies we drop runOnlyAtExecutionRoot, everything else remains,
> BUT
> 3. introduce new mojo aggregate-process (as in PR), that really does what
> it says: will collect all DEPENDENCIES in BULK at parent level. There
> are two shortcomings (as seen in IT_RunOnlyAtExecutionRoot source): it is
> IN BULK, and for this to work, a goal is needed that will produce
> inter-project dependencies, otherwise build fails.
> 
> With these changes all passes OK and IMO the plugin itself became much
> simpler and easier to understand.
> 
> In short, if you have any idea, I am listening!
> 
> 
> Thanks
> T





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