Re: Maven 5 pom extension for agents

[Thomas Reinhardt]

On 20/10/2023 20:43, Romain Manni-Bucau wrote:

Can be the way to define the lookup, an heuristic will never work by
design...that said, on my side, not sure JPMS will be widely adopted
anytime soon so can be a false problem.
This is a chicken and egg problem. My company would love to use JPMS 
more. But right now it is basically unusable for us and part of it is 
lacking maven support. The next big maven release should definitely 
improve the support. One big problem is testing (and all the 
implications with different classpaths etc) but that deserves its own 
discussion I think.





Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :


I think we will need to start rethinking dependencies more. A similar
problem exists with modules; the current heuristics to decide whether a
dependency goes on module path or classpath will start to become painful in
the very near future.

-h


On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell 
wrote:


If you can still use it twice, works for me, too.

Either way, you'd need it both as a dependency and as an agent.

Another requirement Romain mentioned is the order of agent loading.

Mockito

wants to be first, and others can come later.

- Ben




On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  wrote:


What about type=java-agent? Basically a new ArtifactHandler?

See https://maven.apache.org/repositories/artifacts.html

T

On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 

wrote:



Hey all,

In a mockito issue, JDK maintainers suggested to differentiate

between

agents and normal dependencies. Starting with JDK 21 already, this

makes

a

lot of sense: dynamic loading of agents will be a no-go.

One suggestion was:


 
 ...
 
 
 
 ...
 
 


Not sure if this is the best way, but this is something similar might

be

needed.
Currently, the only way to handle agents is to add them manually to

the

surefire argLine. To make things worse, a deoendency goal is needed

until

Romains PR is merged:
https://github.com/apache/maven/pull/1281

Another issue is that a parent pom might not be able to easily define

this

option. There were some concerns that part of the configuration

needed

to

be repeated in every module.

So, I wrote Maven 5.
Maven 4 is the stepping stone to the build/consumer pom. But this is

an

extension. Not really a breaking change in terms of parsing, but in

terms

of building a project. Thus, it should go onto the roadmap.

... unless you want to keep the current status quo, which is also an
option. But before making an argument here, I'd recommend reading the
lengthy (sorry!) discussion on the mockito issue tracker. Since Karl

Heinz

started the issue, I'd love to hear back from you, too. Link:
https://github.com/mockito/mockito/issues/3037

If no discussion is needed at this point, let's keep this as a

reminder

for

the next Apero and/or Maven 5 then.

- Ben











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

Re: [VOTE] Release Apache Maven Clean Plugin version 3.3.2

[Herve Boutemy]

+1

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

Regards,

Hervé

On 2023/10/23 06:11:22 Slawomir Jaranowski wrote:
> Hi,
> 
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2017/
> https://repository.apache.org/content/repositories/maven-2017/org/apache/maven/plugins/maven-clean-plugin/3.3.2/maven-clean-plugin-3.3.2-source-release.zip
> 
> Source release checksum(s):
> maven-clean-plugin-3.3.2-source-release.zip - SHA-512 :
> 7038bca2cc3bc3cdd1dd5d9c363a19150242508e165380feac02bc1b2bf75fee695ecb6fc6f9ed10a3a1ec14f9e46d2963487400b9fce008afa423939b754c5f
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-clean-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
> 
> -- 
> Sławomir Jaranowski
> 

-
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 Apache Maven Clean Plugin version 3.3.2

[Olivier Lamy]

+1

On Mon, 23 Oct 2023 at 16:11, Slawomir Jaranowski
 wrote:
>
> Hi,
>
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2017/
> https://repository.apache.org/content/repositories/maven-2017/org/apache/maven/plugins/maven-clean-plugin/3.3.2/maven-clean-plugin-3.3.2-source-release.zip
>
> Source release checksum(s):
> maven-clean-plugin-3.3.2-source-release.zip - SHA-512 :
> 7038bca2cc3bc3cdd1dd5d9c363a19150242508e165380feac02bc1b2bf75fee695ecb6fc6f9ed10a3a1ec14f9e46d2963487400b9fce008afa423939b754c5f
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-clean-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
>
> --
> Sławomir Jaranowski

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

[ANN] Apache Maven JXR 3.3.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven JXR version 3.3.1


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/jxr/

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


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



Release Notes - Maven JXR - Version 3.3.1

** Improvement
* [JXR-175] - Support Java 14 record as class type in cross reference
* [JXR-176] - Remove dependency org.apache.commons:commons-lang3

** Dependency upgrade
* [JXR-177] - Upgrade Plexus Utils to 3.5.0
* [JXR-178] - Update parent pom to 39
* [JXR-180] - commons-io to 2.14.0
* [JXR-181] - Upgrade to Parent 40


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] Release Maven Dependency Plugin 3.6.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Dependency Plugin version 3.6.1.


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

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


  org.apache.maven.plugins
  maven-dependency-plugin
  3.6.1



Release Notes - Maven Dependency Plugin - Version 3.6.1

** Bug
* [MDEP-875] - Regression: list-repositories may produce NPE

** Dependency upgrade
* [MDEP-868] - maven-shared-utils to 3.4.2
* [MDEP-872] - update commons-io to 2.13.0
* [MDEP-882] - Upgrade plexus-archiver due to CVE-2023-37460
* [MDEP-883] - Upgrade maven-plugin parent to 40


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] Maven Surefire 3.2.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Surefire version 3.2.1.


https://maven.apache.org/surefire/


Release Notes - Maven Surefire - Version 3.2.1

** Bug
* [SUREFIRE-2190] - optional dependencies and JPMS modules confuse 
surefire
* [SUREFIRE-2196] - 
maven-surefire-report-plugin:failsafe-report-only failed: Unmatched 
braces in the pattern
* [SUREFIRE-2202] - NullPointerException if super class meets 
specific condition


** New Feature
* [SUREFIRE-1124] - Let ${surefire.forkNumber} deliver unique 
environmentVariables when used in parallel mvn builds


** Improvement
* [SUREFIRE-2177] - Use junit-bom instead of single JUnit 5 versions
* [SUREFIRE-2178] - classpathDependencyExcludes should support 
classifiers
* [SUREFIRE-2179] - additionalClasspathElements should support 
Maven coordinates

* [SUREFIRE-2182] - Log starter implementation on DEBUG level

** Dependency upgrade
* [SUREFIRE-2188] - Upgrade to Parent 40


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 Maven JXR version 3.3.1

[Michael Osipov]

Hi,

The vote has passed with the following result:

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


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

[RESULT] [VOTE] Release Maven Surefire version 3.2.1

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Hervé Boutemy, Romain Manni-Bucau, Tamás 
Cservenák, Slawomir Jaranowski, Michael Osipov


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

[RESULT] [VOTE] Release Maven Dependency Plugin version 3.6.1

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Hervé Boutemy, Benjamin Marwell, Michael Osipov

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

Re: [VOTE] Release Maven JXR version 3.3.1

[Tamás Cservenák]

+1

On Fri, Oct 20, 2023, 21:45 Michael Osipov  wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12352247
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20JXR%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2012/
>
> https://repository.apache.org/content/repositories/maven-2012/org/apache/maven/jxr/jxr/3.3.1/jxr-3.3.1-source-release.zip
>
> Source release checksum(s):
> jxr-3.3.1-source-release.zip
> sha512:
>
> f200a1b11c4b3bd00c3f9d3dc47a17f3e475c118abb6e4598a15bfacda0672d297f24dd2426bb4b1f0af711361a930431dc73ad7518ce3dd3a01793864893a50
>
> Staging site:
> https://maven.apache.org/jxr-archives/jxr-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 Maven Checkstyle Plugin version 3.3.1

[Tamás Cservenák]

+1

On Sat, Oct 21, 2023, 12:44 Michael Osipov  wrote:

> Hi,
>
> we solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12353283
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project+%3D+MCHECKSTYLE+AND+resolution+%3D+Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2014/
>
> https://repository.apache.org/content/repositories/maven-2014/org/apache/maven/plugins/maven-checkstyle-plugin/3.3.1/maven-checkstyle-plugin-3.3.1-source-release.zip
>
> Source release checksum(s):
> maven-checkstyle-plugin-3.3.1-source-release.zip
> sha512:
>
> 81cae344499ef874d0a287f4c3c6a6b079ac09c6674b8e3bbb7cb7e527300ccaa43277b3b9387a482291e709546f12e89ff08bb596d894967a0cb1e7cefd7e16
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-checkstyle-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
>
>

Re: [VOTE] Release Apache Maven Clean Plugin version 3.3.2

[Tamás Cservenák]

+1

On Mon, Oct 23, 2023, 08:11 Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2017/
>
> https://repository.apache.org/content/repositories/maven-2017/org/apache/maven/plugins/maven-clean-plugin/3.3.2/maven-clean-plugin-3.3.2-source-release.zip
>
> Source release checksum(s):
> maven-clean-plugin-3.3.2-source-release.zip - SHA-512 :
>
> 7038bca2cc3bc3cdd1dd5d9c363a19150242508e165380feac02bc1b2bf75fee695ecb6fc6f9ed10a3a1ec14f9e46d2963487400b9fce008afa423939b754c5f
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-clean-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
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven Docck Plugin version 1.2

[Tamás Cservenák]

+1

On Sun, Oct 22, 2023, 16:21 Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317229=12342769
>
> NOTE: This is the last release - preparing for the retiring plugin.
> So all remaining issues will be closed - as won't fix.
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2016/
>
> https://repository.apache.org/content/repositories/maven-2016/org/apache/maven/plugins/maven-docck-plugin/1.2/maven-docck-plugin-1.2-source-release.zip
>
> Source release checksum(s):
> maven-docck-plugin-1.2-source-release.zip - SHA-512 :
>
> 46d97660c8a4a144957e6585958cf5cf3798b6971d21fa9f55f097938ce021ff533d19705f0f456e1b80e968bf24bb2d6c90ae80b484e6ab839ab2ee50ac6527
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-docck-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
>
> --
> Sławomir Jaranowski
>

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

[Maarten Mulders]

+1

Thanks for rolling this release!

Maarten

On 20/10/2023 23:37, 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=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:

7264b5ae1a567ff9249f8020bc5713386f26bdd297b499e309a70897d03b647ef5a1446d10963529fd50dbab0ee56f5357ab39405462b8a5326a99bae80222c9

apache-maven-4.0.0-alpha-8-src.tar.gz sha512:

d645e4015119836428e16bd5d4dd29bed6d4983d552445cdf587a61f0a2347a619e9de02cdc590eda000c4561e60e33e758aa83dca3d6243ede97f5be981b322


Binary release checksums:
apache-maven-4.0.0-alpha-8-bin.zip sha512:

6aa9486e2d880b691580e0071347022b6426f0a6b2c6549879b6a848a4494c70ff8dff25ffe8de2edd82583d7119bf359156ece0f9ef18f1c99ff3db776461f3

apache-maven-4.0.0-alpha-8-bin.tar.gz sha512:

7646b5bbaa0b81e600076055134ba88d5bd02d7a0ae03829b7e217aad9e47c25a3edbf4b091562d4bc9d93b5a50e84449a679f18052dc4f97d0314a8bc9dd961


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/21deeaf4a0fc4993e0091d214f194195dc66c167/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 release has been built and uploaded with 4.0.0-alpha-8
itself, which means it uses the new build and consumer POMs...

Vote open for 72h

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

Cheers
Guillaume



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

Re: Maven 5 pom extension for agents

[Romain Manni-Bucau]

the point is that if you open, as you mention, a system you always end up
having compatibility matrix - no plugin except yours will read your meta -
so this becomes a nightmare for end users, whereas when there is a standard
way - no built-in extensibility - then you never have this issue and it is
generally better for users.
I'm still on the side to make it easy for users even if it costs a bit more
to us and plugin dev.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 23 oct. 2023 à 12:05, Christoph Läubrich  a
écrit :

>  > Exactly the opposite right?
>
> of what?
>
>  > If we do that then a particular plugin can use that but all others
>  > will don't read it right
>
> Whats "right" depends on the context, at least one don't need a new
> discussion/extension for each use case, also most of these discussions
> cover the needs of the maven-* plugins but often forget custom plugins
> that have other demands apart from "everyone can use this for everything".
>
>  > until you rewrite the full maven plugin ecosystem
>
> Usually such things don't touch really *everything" and especially this
> will not require a rewrite for anything but the same as a new 
> element would need beside that  will always only cover one
> specific use-case, while allowing generic extensibility would allow to
> cover a wide range of use-cases.
>
> Am 23.10.23 um 11:34 schrieb Romain Manni-Bucau:
> > Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich  a
> > écrit :
> >
> >> I always wished there was support for generic  element in
> >>  this can then be literally used for everything in an
> >> extensible way.
> >>
> >> 
> >>  
> >>... usual stuff ...
> >>   
> >>module
> >>...
> >>   
> >>  
> >> 
> >>
> >
> > Exactly the opposite right?
> > If we do that then a particular plugin can use that but all others will
> > don't read it right so ultimately you reach the exact opposite of what
> you
> > aim for until you rewrite the full maven plugin ecosystem which is
> > obviously not the goal IMHO.
> >
> >
> >>
> >> Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:
> >>> Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :
> >>>
>  that said, on my side, not sure JPMS will be widely adopted anytime
>  soon so can be a false problem.
> 
> >>> I think that this is a chicken-and-egg problem: some peoples renounce
> to
> >>> JPMS because tools support is poor (at least in Maven and Gradle), and
> >>> tools don't improve their support because they think that JPMS is not
> >>> widely-used. We sometime see in mailing lists or blogs blames saying
> >>> that JPMS is half-backed, while actually the problem lies in the tools.
> >>>
> >>> Regarding the original proposal, I would suggest an amendment for
> >>> addressing more problems at once: not only agent, but also doclet,
> >>> annotation processor and one aspect of JPMS. Instead of an 
> block
> >>> in , I suggest a new  element inside 
> >>> saying where to put that dependency. Example:
> >>>
> >>>  
> >>> 
> >>>   ... usual stuff ...
> >>>   module
> >>> 
> >>>  
> >>>
> >>> Where  can contain a comma-separated list of the following:
> >>>
> >>>  class, module, processor-class, processor-module, doclet, agent
> >>>
> >>> where
> >>>
> >>>* class and module are mutually exclusive,
> >>>* processor-class and processor-module are mutually exclusive.
> >>>
> >>> This is not exactly the same as the existing  element because
> >>>  changes the artifact to use (main versus test) without changing
> >>> where to put it (class-path versus module-path), while the proposed
> >>>  is the converse.
> >>>
> >>>   Martin
> >>>
> >>>
> >>
> >> -
> >> 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: Maven 5 pom extension for agents

[Christoph Läubrich]

> Exactly the opposite right?

of what?

> If we do that then a particular plugin can use that but all others
> will don't read it right

Whats "right" depends on the context, at least one don't need a new 
discussion/extension for each use case, also most of these discussions 
cover the needs of the maven-* plugins but often forget custom plugins 
that have other demands apart from "everyone can use this for everything".


> until you rewrite the full maven plugin ecosystem

Usually such things don't touch really *everything" and especially this 
will not require a rewrite for anything but the same as a new  
element would need beside that  will always only cover one 
specific use-case, while allowing generic extensibility would allow to 
cover a wide range of use-cases.


Am 23.10.23 um 11:34 schrieb Romain Manni-Bucau:

Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich  a
écrit :


I always wished there was support for generic  element in
 this can then be literally used for everything in an
extensible way.


 
   ... usual stuff ...
  
   module
   ...
  
 




Exactly the opposite right?
If we do that then a particular plugin can use that but all others will
don't read it right so ultimately you reach the exact opposite of what you
aim for until you rewrite the full maven plugin ecosystem which is
obviously not the goal IMHO.




Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:

Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :


that said, on my side, not sure JPMS will be widely adopted anytime
soon so can be a false problem.


I think that this is a chicken-and-egg problem: some peoples renounce to
JPMS because tools support is poor (at least in Maven and Gradle), and
tools don't improve their support because they think that JPMS is not
widely-used. We sometime see in mailing lists or blogs blames saying
that JPMS is half-backed, while actually the problem lies in the tools.

Regarding the original proposal, I would suggest an amendment for
addressing more problems at once: not only agent, but also doclet,
annotation processor and one aspect of JPMS. Instead of an  block
in , I suggest a new  element inside 
saying where to put that dependency. Example:

 

  ... usual stuff ...
  module

 

Where  can contain a comma-separated list of the following:

 class, module, processor-class, processor-module, doclet, agent

where

   * class and module are mutually exclusive,
   * processor-class and processor-module are mutually exclusive.

This is not exactly the same as the existing  element because
 changes the artifact to use (main versus test) without changing
where to put it (class-path versus module-path), while the proposed
 is the converse.

  Martin




-
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: Maven 5 pom extension for agents

[Martin Desruisseaux]

Le 2023-10-23 à 11 h 48, Romain Manni-Bucau a écrit :

(…snip…) but still, I don't think we need that for the mentionned issue.


For agents, alternatives have indeed been proposed in this thread. But 
some form of usage specification (either as  element or 
 composition) will be needed anyway at least for JPMS, 
and could opportunistically be used for doclet and processor path as 
well, thus providing a more centralized way to specify all sorts of 
path. If such mechanism is implemented anyway, then agent could 
opportunistically uses it as well. Even if not sufficient, this common 
part can be completed by agent-specific and JPMS-specific options.


    Martin

Re: Maven 5 pom extension for agents

[Martin Desruisseaux]

Le 2023-10-23 à 11 h 28, Romain Manni-Bucau a écrit :


anyway, if we go with the "usages" path we can want to enable a 
 definition containing  wrapped in a 
scope () this way you 
can reference a dependency set in a plugin or even main dependencies 
(import all).


Maybe, but the  element has the advantage of allowing the same 
dependency to be put in different kinds of path (doclet, annotation 
processor, etc.) while the  approach would require to 
repeat the dependencies.



That said, as mentionned, it does *not* solve the issue for agents due 
to the inheritance nature where order will be lost until we add an 
order attribute/element.


The  element alone may not be sufficient for covering all agent 
needs, in the same way as it is not sufficient for covering all JPMS 
needs. We will have more complexity to handle anyway: ordering for 
agents, add-exports/add-opens for JPMS. But the  element offer a 
common place where to handle a common problem.


Regarding ordering, this is important for classpath as well. Can't it be 
just the ordering of  elements in the POM?


    Martin

Re: Maven 5 pom extension for agents

[Romain Manni-Bucau]

Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich  a
écrit :

> I always wished there was support for generic  element in
>  this can then be literally used for everything in an
> extensible way.
>
> 
> 
>   ... usual stuff ...
>  
>   module
>   ...
>  
> 
> 
>

Exactly the opposite right?
If we do that then a particular plugin can use that but all others will
don't read it right so ultimately you reach the exact opposite of what you
aim for until you rewrite the full maven plugin ecosystem which is
obviously not the goal IMHO.


>
> Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:
> > Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :
> >
> >> that said, on my side, not sure JPMS will be widely adopted anytime
> >> soon so can be a false problem.
> >>
> > I think that this is a chicken-and-egg problem: some peoples renounce to
> > JPMS because tools support is poor (at least in Maven and Gradle), and
> > tools don't improve their support because they think that JPMS is not
> > widely-used. We sometime see in mailing lists or blogs blames saying
> > that JPMS is half-backed, while actually the problem lies in the tools.
> >
> > Regarding the original proposal, I would suggest an amendment for
> > addressing more problems at once: not only agent, but also doclet,
> > annotation processor and one aspect of JPMS. Instead of an  block
> > in , I suggest a new  element inside 
> > saying where to put that dependency. Example:
> >
> > 
> >
> >  ... usual stuff ...
> >  module
> >
> > 
> >
> > Where  can contain a comma-separated list of the following:
> >
> > class, module, processor-class, processor-module, doclet, agent
> >
> > where
> >
> >   * class and module are mutually exclusive,
> >   * processor-class and processor-module are mutually exclusive.
> >
> > This is not exactly the same as the existing  element because
> >  changes the artifact to use (main versus test) without changing
> > where to put it (class-path versus module-path), while the proposed
> >  is the converse.
> >
> >  Martin
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 5 pom extension for agents

[Christoph Läubrich]

I always wished there was support for generic  element in 
 this can then be literally used for everything in an 
extensible way.



   
 ... usual stuff ...

 module
 ...

   


Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:

Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :

that said, on my side, not sure JPMS will be widely adopted anytime 
soon so can be a false problem.


I think that this is a chicken-and-egg problem: some peoples renounce to 
JPMS because tools support is poor (at least in Maven and Gradle), and 
tools don't improve their support because they think that JPMS is not 
widely-used. We sometime see in mailing lists or blogs blames saying 
that JPMS is half-backed, while actually the problem lies in the tools.


Regarding the original proposal, I would suggest an amendment for 
addressing more problems at once: not only agent, but also doclet, 
annotation processor and one aspect of JPMS. Instead of an  block 
in , I suggest a new  element inside  
saying where to put that dependency. Example:


    
   
     ... usual stuff ...
     module
   
    

Where  can contain a comma-separated list of the following:

    class, module, processor-class, processor-module, doclet, agent

where

  * class and module are mutually exclusive,
  * processor-class and processor-module are mutually exclusive.

This is not exactly the same as the existing  element because 
 changes the artifact to use (main versus test) without changing 
where to put it (class-path versus module-path), while the proposed 
 is the converse.


     Martin




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

Re: Maven 5 pom extension for agents

[Romain Manni-Bucau]

well chicken-egg or just lack of need (from my window the people you
reference are very few and mainly testers)

anyway, if we go with the "usages" path we can want to enable a <
dependenciesSet> definition containing  wrapped in a scope
() this way you can
reference a dependency set in a plugin or even main dependencies (import
all).

That said, as mentionned, it does *not* solve the issue for agents due to
the inheritance nature where order will be lost until we add an order
attribute/elementand ultimately we are already way more complicated
than the existing solution which works well so I still think we are running
after a horse which already passed the finish line.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 23 oct. 2023 à 11:25, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :
>
> > that said, on my side, not sure JPMS will be widely adopted anytime
> > soon so can be a false problem.
> >
> I think that this is a chicken-and-egg problem: some peoples renounce to
> JPMS because tools support is poor (at least in Maven and Gradle), and
> tools don't improve their support because they think that JPMS is not
> widely-used. We sometime see in mailing lists or blogs blames saying
> that JPMS is half-backed, while actually the problem lies in the tools.
>
> Regarding the original proposal, I would suggest an amendment for
> addressing more problems at once: not only agent, but also doclet,
> annotation processor and one aspect of JPMS. Instead of an  block
> in , I suggest a new  element inside 
> saying where to put that dependency. Example:
>
> 
>
>  ... usual stuff ...
>  module
>
> 
>
> Where  can contain a comma-separated list of the following:
>
> class, module, processor-class, processor-module, doclet, agent
>
> where
>
>   * class and module are mutually exclusive,
>   * processor-class and processor-module are mutually exclusive.
>
> This is not exactly the same as the existing  element because
>  changes the artifact to use (main versus test) without changing
> where to put it (class-path versus module-path), while the proposed
>  is the converse.
>
>  Martin
>
>

Re: Maven 5 pom extension for agents

[Martin Desruisseaux]

Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :

that said, on my side, not sure JPMS will be widely adopted anytime 
soon so can be a false problem.


I think that this is a chicken-and-egg problem: some peoples renounce to 
JPMS because tools support is poor (at least in Maven and Gradle), and 
tools don't improve their support because they think that JPMS is not 
widely-used. We sometime see in mailing lists or blogs blames saying 
that JPMS is half-backed, while actually the problem lies in the tools.


Regarding the original proposal, I would suggest an amendment for 
addressing more problems at once: not only agent, but also doclet, 
annotation processor and one aspect of JPMS. Instead of an  block 
in , I suggest a new  element inside  
saying where to put that dependency. Example:


   
  
... usual stuff ...
module
  
   

Where  can contain a comma-separated list of the following:

   class, module, processor-class, processor-module, doclet, agent

where

 * class and module are mutually exclusive,
 * processor-class and processor-module are mutually exclusive.

This is not exactly the same as the existing  element because 
 changes the artifact to use (main versus test) without changing 
where to put it (class-path versus module-path), while the proposed 
 is the converse.


    Martin

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

[Guillaume Nodet]

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.


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


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


> - I suppose I'll have to add BOM packaging documentation to
> https://maven.apache.org/ref/4-LATEST/maven-core/default-bindings.html
>
> 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=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:
> > >
> > >
> 7264b5ae1a567ff9249f8020bc5713386f26bdd297b499e309a70897d03b647ef5a1446d10963529fd50dbab0ee56f5357ab39405462b8a5326a99bae80222c9
> > >
> > > apache-maven-4.0.0-alpha-8-src.tar.gz sha512:
> > >
> > >
> d645e4015119836428e16bd5d4dd29bed6d4983d552445cdf587a61f0a2347a619e9de02cdc590eda000c4561e60e33e758aa83dca3d6243ede97f5be981b322
> > >
> > >
> > > Binary release checksums:
> > > apache-maven-4.0.0-alpha-8-bin.zip sha512:
> > >
> > >
> 6aa9486e2d880b691580e0071347022b6426f0a6b2c6549879b6a848a4494c70ff8dff25ffe8de2edd82583d7119bf359156ece0f9ef18f1c99ff3db776461f3
> > >
> > > apache-maven-4.0.0-alpha-8-bin.tar.gz sha512:
> > >
> > >
> 7646b5bbaa0b81e600076055134ba88d5bd02d7a0ae03829b7e217aad9e47c25a3edbf4b091562d4bc9d93b5a50e84449a679f18052dc4f97d0314a8bc9dd961
> > >
> > >
> > > 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/21deeaf4a0fc4993e0091d214f194195dc66c167/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 release has been built and uploaded with 4.0.0-alpha-8
> > > itself, which means it uses the new build and consumer POMs...
> > >
> > > Vote open for 72h
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > Cheers
> > > Guillaume
> > >
> >
> > -
> > 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, 

[VOTE] Release Apache Maven Clean Plugin version 3.3.2

[Slawomir Jaranowski]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-2017/
https://repository.apache.org/content/repositories/maven-2017/org/apache/maven/plugins/maven-clean-plugin/3.3.2/maven-clean-plugin-3.3.2-source-release.zip

Source release checksum(s):
maven-clean-plugin-3.3.2-source-release.zip - SHA-512 :
7038bca2cc3bc3cdd1dd5d9c363a19150242508e165380feac02bc1b2bf75fee695ecb6fc6f9ed10a3a1ec14f9e46d2963487400b9fce008afa423939b754c5f

Staging site:
https://maven.apache.org/plugins-archives/maven-clean-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

-- 
Sławomir Jaranowski