from:"Tamás Cservenák"

+1

On Sat, May 25, 2024 at 11:39 AM Michael Osipov  wrote:

> Hi,
>
> IMPORTANT: This require the following staging repositories:
>
> * Maven Reporting Impl 4.0.0-M15
>
> we solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12354658
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-exec
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2130/
>
> https://repository.apache.org/content/repositories/maven-2130/org/apache/maven/reporting/maven-reporting-exec/2.0.0-M14/maven-reporting-exec-2.0.0-M14-source-release.zip
>
> Source release checksum(s):
> maven-reporting-exec-2.0.0-M14-source-release.zip
> sha512:
>
> 2dfbb2d223b2478822b6fee028d714ca838ab04cfa8b4c8cf10f66aee1b872c8aae99b0cf5122a00e19d3ca2b3717c80ad536ce31ca492791364235da1d98549
>
> 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
>
>

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

+1

On Sat, May 25, 2024 at 11:27 AM Michael Osipov  wrote:

> Hi,
>
> we solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12354657
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2129/
>
> https://repository.apache.org/content/repositories/maven-2129/org/apache/maven/reporting/maven-reporting-impl/4.0.0-M15/maven-reporting-impl-4.0.0-M15-source-release.zip
>
> Source release checksum(s):
> maven-reporting-impl-4.0.0-M15-source-release.zip
> sha512:
>
> 7975981de217af3c8e8e43f82c38c0c5dad034345c11b42ffdf98992b9eef3fd4a7bf34ae3f877280ecdb43b57b215cec8f6cdc732fcafd35a6c8508d0552b7f
>
> 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
>
>

Re: [VOTE] Release Apache Maven Dependency Tree version 3.3.0

+1

On Sun, May 26, 2024 at 8:22 PM Michael Osipov  wrote:

> Hi,
>
> NOTE: This is expected to be the last release of this component.
>
> we solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12348675
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-tree
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2132/
>
> https://repository.apache.org/content/repositories/maven-2132/org/apache/maven/shared/maven-dependency-tree/3.3.0/maven-dependency-tree-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-dependency-tree-3.3.0-source-release.zip
> sha512:
>
> b9e8c3cda43a0ad54ea80795cc265c49f4196fe23c0494a1abacb37ac424209c171b0c64da141302d4cf579a83ba92053ca00b5b6092817cd499abfe6c83cbb1
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-tree-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 Enforcer version 3.5.0

+1

On Sun, May 26, 2024, 19:52 Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12353621
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MENFORCER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2131/
>
> https://repository.apache.org/content/repositories/maven-2131/org/apache/maven/enforcer/enforcer/3.5.0/enforcer-3.5.0-source-release.zip
>
> Source release checksum(s):
> enforcer-3.5.0-source-release.zip - SHA-512 :
>
> a8d91fe9f0a47746af8c0a0c9287350750dc2fc342b73f14ff9d0f32cb2b4c1c9ba727d7a5924644cd22d12bbef70474c7404d5c06858585595af085e761d095
>
> Staging site:
> https://maven.apache.org/enforcer-archives/enforcer-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 4.0.0-beta-3 released

The Apache Maven team is pleased to announce the release of the
Apache Maven 4.0.0-beta-3

Apache Maven is a software project management and comprehension tool. Based
on the concept of a project object model (POM), Maven can manage a
project's build, reporting and documentation from a central piece of
information.

Maven 4.0.0-beta-3 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of
plugins will be made separately.

If you have any questions, please consult:

- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the reference documentation: https://maven.apache.org/ref/4.0.0-beta-3/

For more information read
https://maven.apache.org/docs/4.0.0-beta-3/release-notes.html


Release Notes - Maven - Version 4.0.0-beta-3

** Bug
* [MNG-8025] - API incompatibility with m-remote-resources-p
* [MNG-8079] - Maven Resolver breaks compatibility due Resolver breakage
* [MNG-8082] - Exceptions of proxied SessionScoped components are not
working correctly
* [MNG-8106] - Maven Metadata corruption if repository directory role
overlaps
* [MNG-8108] - Failure to create the consumer POM
* [MNG-8118] - Dependency-management "client" exclusions overwrite BOM
exclusions
* [MNG-8121] - NullPointerException at
org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)
* [MNG-8123] - Maven 4.0.0-beta-2 fails with
maven-build-cache-extension 1.2.0
** New Feature
* [MNG-8084] - Make the v4 api usable outside the Maven runtime
** Improvement
* [MNG-8015] - Control the type of path where each dependency can be
placed
* [MNG-8038] - Model builder API
* [MNG-8050] - Same repositories IDs in settings.xml and POM are not
detected
* [MNG-8075] - Allow project.baseUri in repository.url
* [MNG-8081] - default profile activation should consider available
system and user properties
* [MNG-8085] - switch from png+imagemap to svg
* [MNG-8089] - Introduce "fat" type for JAR
* [MNG-8117] - Improve prerequisite evaluation and plugin version
selection logging
* [MNG-8119] - Remove build section in consumer pom profiles
* [MNG-8128] - Custom packaging not found
** Task
* [MNG-8043] - Dependency properties should be provided by Resolver
consumer
* [MNG-8070] - Document Maven Runtime Requirement for Java 17
* [MNG-8073] - Generated XSD files needs to have ASL2.0 license headers
* [MNG-8088] - Apply Resolver ScopeManager
** Dependency upgrade
* [MNG-8091] - Update Resolver to 2.0.0-alpha-10
* [MNG-8102] - Upgrade Parent to 42
* [MNG-8103] - Upgrade default plugin bindings
* [MNG-8105] - Upgrade to JLine 3.26.0
* [MNG-8107] - Upgrade to Resolver 2.0.0-alpha-11

Have fun!
- The Maven TeaM

[RESULT][VOTE] Release Apache Maven 4.0.0-beta-3

Howdy,

The vote has passed with the following result:

+1b: Karl-Heinz, Romain, Tamas, Olivier, Slawomir
+1nb: Mateusz

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

All, thanks a LOT for participating and casting votes!

Thanks
T

PS: Guillaume is not available today, with his approval I am taking over
the last steps for release.

Re: Maven 3.9.7 and "file locking"

What I left out:
same stands for Maven4, latest beta-3 (coming soon) contains the same fix.

On Sat, May 25, 2024 at 7:35 PM Tamás Cservenák  wrote:

> Howdy,
>
> I would like to ask users who are using "file locking" to upgrade to 3.9.7
> and report back.
>
> The "hot artifacts" theory (as explained in [1]) proved to be right, but
> NOT due to reason as originally assumed, but due to bug (see [2]).
>
> TIA
> Tamas
>
> [1]
> https://issues.apache.org/jira/browse/MNG-7868?focusedCommentId=17762618=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17762618
> [2] https://issues.apache.org/jira/browse/MRESOLVER-522
>

Maven 3.9.7 and "file locking"

Howdy,

I would like to ask users who are using "file locking" to upgrade to 3.9.7
and report back.

The "hot artifacts" theory (as explained in [1]) proved to be right, but
NOT due to reason as originally assumed, but due to bug (see [2]).

TIA
Tamas

[1]
https://issues.apache.org/jira/browse/MNG-7868?focusedCommentId=17762618=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17762618
[2] https://issues.apache.org/jira/browse/MRESOLVER-522

[ANN] Apache Maven 3.9.7 released

The Apache Maven team is pleased to announce the release of the
Apache Maven 3.9.7

Apache Maven is a software project management and comprehension tool. Based
on the concept of a project object model (POM), Maven can manage a
project's build, reporting and documentation from a central piece of
information.

Maven 3.9.7 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of
plugins will be made separately.

If you have any questions, please consult:

- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the reference documentation: https://maven.apache.org/ref/3.9.7/

For more information read
https://maven.apache.org/docs/3.9.7/release-notes.html

Release Notes - Maven - Version 3.9.7

** Bug
* [MNG-8106] - Maven Metadata corruption if repository directory role
overlaps
* [MNG-8121] - NullPointerException at
org.apache.maven.artifact.repository.metadata.Metadata.merge
(Metadata.java:293)
** New Feature
* [MNG-5726] - Update OS Activation To Allow Wildcards In OS Version
* [MNG-8030] - Backport: Add ability to ignore dependency repositories:
mvn -itr
** Improvement
* [MNG-8019] - Streamline update policy of pluginRepository/repository
of Maven Central in Super POM
* [MNG-8029] - improve documentation of mirror in settings
* [MNG-8031] - Backport: Make Maven transfer listener used with
Resolver more concurrent friendly
* [MNG-8081] - default profile activation should consider available
system and user properties
* [MNG-8085] - swtich from png+imagemap to svg
* [MNG-8117] - Improve prerequisite evaluation and plugin version
selection logging
** Task
* [MNG-7309] - Remove redundant MojoDescriptor parameterMap
* [MNG-8011] - Minimize and make generic the README.txt
* [MNG-8055] - Investigate possible solutions for build number diffs on
deploy
** Dependency upgrade
* [MNG-8094] - Resolver 1.9.19
* [MNG-8100] - Upgrade default plugin bindings
* [MNG-8101] - Upgrade Parent to 42
* [MNG-8109] - Resolver 1.9.20
* [MNG-8115] - Upgrade minimal set of dependencies
* [MNG-8125] - (build) Bump buildhelper-maven-plugin to 3.6.0 (was
3.4.0)
* [MNG-8126] - Bump logback classic to 1.2.13 (was 1.2.12)
* [MNG-8127] - Bump guava to 33.2.0-jre

Have fun!
- The Maven Team

[RESULT][VOTE] Release Apache Maven 3.9.7

Howdy,

The vote has passed with the following result:

+1b: Karl-Heinz, Michael, Slawomir, Olivier, Guillaume, Benjamin
+1nb: Tony, Romain, Mateusz, Matthias, Michael, Jorge

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

All, thanks a LOT for participating and casting votes!

Thanks
T

[ANN] Apache Maven Wrapper 3.3.2 Released

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

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

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

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

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

Release Notes - Maven Wrapper - Version 3.3.2

** Bug
* [MWRAPPER-136] - maven-wrapper.properties created with Windows line
breaks which mvnw can't handle
* [MWRAPPER-137] - Can't match distributionUrl when using MINGW64
* [MWRAPPER-139] - Shell scripts break on LF in config for Windows
* [MWRAPPER-140] - only-script Type does not honor MAVEN_USER_HOME
** Improvement
* [MWRAPPER-141] - Use distribution type of existing Maven Wrapper by
default
** Task
* [MWRAPPER-135] - Provide a reliable way to determine the Maven
Wrapper type

Enjoy,
-The Apache Maven team

[RESULT][VOTE] Release Apache Maven Wrapper 3.3.2

Howdy,

The vote has passed with the following result:

+1b: Manfred, Romain, Slawomir, Sylwester, Karl-Heinz, Tamas

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Apache Maven Wrapper 3.3.2

+1

On Tue, May 21, 2024 at 5:17 PM Tamás Cservenák  wrote:

> Howdy,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354608
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MWRAPPER/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2124/
>
> Source release checksum SHA512:
>
> 620d6945ad3a18cc80da52ad81af452524cf427b24adcff1a83ad77a0d0e72dd18825e2c5e4405e43babe8e6fd52e83cef58b10d39b55fa8a4bba9a7801d66a5
>
> Staging site:
> https://maven.apache.org/wrapper-archives/wrapper-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
>

[RESULT][VOTE] Release Maven Resolver Ant Tasks 1.5.1

Howdy,

The vote has passed with the following result:

+1b: Slawomir, Sylwester, Tamas

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.1

+1

On Tue, May 21, 2024 at 1:13 PM Tamás Cservenák  wrote:

> Howdy,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353627
>
> There are still some issues in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20%22Ant%20Tasks%22
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2123/
>
> Source release SHA512:
>
> fdeba5927b93693e8d926e9af442434634d4a8656c4392b36c2ab88e0c790304d1b8f49d576d7d6bdc4d8099a4d770b9212bbaf53bb61fe9a199e26d3d583a03
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.7.0

2024-05-23 Thread Tamás Cservenák

+1

On Thu, May 23, 2024 at 12:05 AM Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525=12354467
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINVOKER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2128/
>
> https://repository.apache.org/content/repositories/maven-2128/org/apache/maven/plugins/maven-invoker-plugin/3.7.0/maven-invoker-plugin-3.7.0-source-release.zip
>
> Source release checksum(s):
> maven-invoker-plugin-3.7.0-source-release.zip - SHA-512 :
>
> f85e038b4b24e1f89940094d44059d0aacc9197975e0bf5b98bd616f649fd08f557c097dc72bd46866ba529499ade40f9400107200bd7461851a8f1205fae821
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-invoker-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 Doxia Sitetools version 2.0.0-M19

2024-05-23 Thread Tamás Cservenák

+1

On Wed, May 22, 2024 at 9:46 PM Michael Osipov  wrote:

> Hi,
>
> we solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12354630
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2127
>
> https://repository.apache.org/content/repositories/maven-2127/org/apache/maven/doxia/doxia-sitetools/2.0.0-M19/doxia-sitetools-2.0.0-M19-source-release.zip
>
> Source release checksum(s):
> doxia-sitetools-2.0.0-M19-source-release.zip
> sha512:
>
> 44a6dacc3ed5a4507c92a60e568862abeeb0ceb3bf0b3a812f2ae5ed779bb7cd711a28e3f70d2df2c5e29caddc596dd83e3840d21d99cac4b3f7f6baecff04aa
>
> Staging site:
>
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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 4.0.0-beta-3

2024-05-23 Thread Tamás Cservenák

+1

On Wed, May 22, 2024 at 5:12 PM Guillaume Nodet  wrote:

> This is a vote to release Apache Maven 4.0.0-beta-3, as I've cut another
> release to fix blocking issues found in beta-2.
>
>
> We solved 25 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354634
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MNG/issues
>
> Release candidates:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-beta-3/
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2126/
>
> Source release SHA512:
> - apache-maven-4.0.0-beta-3-src.zip
>
> 4125acba32218e341b34c1bbe7700f5aa71947fd1a6a5d418825822099800e3b798a5300eaf711e0709866b7e5fc6fee323515af18d8ab25d7eaac034d72b1c6
> - apache-maven-4.0.0-beta-3-src.tar.gz
>
> 8ca063a72fdacbcbe4afc33fc46e6c8920327092d11f3d8a77723ce995c3e24d1e8413cce3d5bc59a47657316834bfb9d4706d8bdffa5da5e147bcb404381808
>
> Staging site:
> https://maven.apache.org/ref/4-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> The vote is open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Guillaume Nodet
>

Re: [VOTE] Release Apache Maven 3.9.7

2024-05-22 Thread Tamás Cservenák

Hej Gary

I agree, and TBH i moved MNG-8030 to "new feature", originally it was
improvement (and now would move it back).

The -itr OTOH is "new feature" as in it makes really simple to ignore
"remote repositories introduced by transitive POMs" but you could achieve
similar effect with already existing features as well (but not so simple).
This, combined with RRF (remote repo filtering) is a killer feature. We
just wanted it out in the wild.

My 5 cents
T

On Wed, May 22, 2024, 22:50 Gary D. Gregory  wrote:

> Hi All:
>
> As a user, I don't expect 2 new features in a maintenance release.
> It would be nice to use semantic versioning to manage expectations.
>
> 2c & TY!
> Gary
>
> On 2024/05/22 10:09:20 Tamás Cservenák wrote:
> > Howdy,
> >
> > We solved 21 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353964
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2125/
> >
> > Dev dist directory (binary bundles updated):
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/
> >
> > Source release checksums:
> > apache-maven-3.9.7-src.tar.gz.sha512
> >
> a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1
> >
> > apache-maven-3.9.7-src.zip.sha512
> >
> cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/521
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72h
> >
> > [ ] +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 3.9.7

2024-05-22 Thread Tamás Cservenák

Howdy,

We solved 21 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353964

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2125/

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/

Source release checksums:
apache-maven-3.9.7-src.tar.gz.sha512
a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1

apache-maven-3.9.7-src.zip.sha512
cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/521

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

Vote open for 72h

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

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.14.1

+1

On Sun, May 19, 2024, 21:01 Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353208
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-analyzer
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2121/
>
> https://repository.apache.org/content/repositories/maven-2121/org/apache/maven/shared/maven-dependency-analyzer/1.14.1/maven-dependency-analyzer-1.14.1-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.14.1-source-release.zip - SHA-512 :
>
> 4f964fe540b6296bfdc4b60e29cf4d9c92aae2518c43fa0359e1e415c81337ed107e28ac2fbd681ea8e4bb85f6a3dfb8c0086fc7bb8c663d4679c90146be43b5
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-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 Maven Fluido Skin version 2.0.0-M9

+1

On Mon, May 20, 2024, 10:55 Michael Osipov  wrote:

> Hi,
>
> we solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926=12353690
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSKINS%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Fluido%20Skin%22
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2122/
>
> https://repository.apache.org/content/repositories/maven-2122/org/apache/maven/skins/maven-fluido-skin/2.0.0-M9/maven-fluido-skin-2.0.0-M9-source-release.zip
>
> Source release checksum(s):
> maven-fluido-skin-2.0.0-M9-source-release.zip
> sha512:
>
> 73c6ddaf32433d2f24b36f838979ad60ea2c0984521e8c71c28639a20c67131884afc14b5a319e07cfc3de80d818c03c0cc73b40f29de715c4966f633cf983e6
>
> Staging site:
>
> https://maven.apache.org/components/skins-archives/maven-fluido-skin-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
>
>

[VOTE] Release Apache Maven Wrapper 3.3.2

Howdy,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354608

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MWRAPPER/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2124/

Source release checksum SHA512:
620d6945ad3a18cc80da52ad81af452524cf427b24adcff1a83ad77a0d0e72dd18825e2c5e4405e43babe8e6fd52e83cef58b10d39b55fa8a4bba9a7801d66a5

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

[VOTE] Release Maven Resolver Ant Tasks 1.5.1

Howdy,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353627

There are still some issues in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20%22Ant%20Tasks%22

Staging repository:
https://repository.apache.org/content/repositories/maven-2123/

Source release SHA512:
fdeba5927b93693e8d926e9af442434634d4a8656c4392b36c2ab88e0c790304d1b8f49d576d7d6bdc4d8099a4d770b9212bbaf53bb61fe9a199e26d3d583a03

Staging site:
https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/

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

Vote open for 72 hours.

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

[ANN] Apache Maven Indexer 7.1.3 released

The Apache Maven team is pleased to announce the release of the
Maven Indexer 7.1.3

https://maven.apache.org/maven-indexer/

Release Notes - Maven Indexer - Version 7.1.3

** Improvement
* [MINDEXER-222] - RR backend in case of GAVCE search should use
Last-Modified HTTP header
** Dependency upgrade
* [MINDEXER-216] - Bump commons-cli:commons-cli from 1.6.0 to 1.7.0
* [MINDEXER-217] - Bump org.apache.maven:maven-parent from 41 to 42
* [MINDEXER-218] - Bump org.jmock:jmock from 2.12.0 to 2.13.1
* [MINDEXER-219] - Bump com.google.guava:guava from 32.1.3-jre to
33.1.0-jre
* [MINDEXER-220] - Bump lucene.version from 9.9.1 to 9.10.0
* [MINDEXER-221] - (build) Bump org.gaul:modernizer-maven-plugin from
2.7.0 to 2.8.0
* [MINDEXER-223] - Upgrade slf4j to version 2.0.13

Have fun,
-The Apache Maven team

[RESULT][VOTE] Release Maven Indexer 7.1.3

Howdy,

The vote has passed with the following result:

+1b: Michael, Slawomir, Olivier, Tamas

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

[DISCUSS] Many shared stuff should be dropped

Howdy,

I see ongoing development against many "shared" libraries, that in fact,
should be dropped instead. One notable example is "maven-dependency-tree".

This codebase was born (well, factored out) from Maven2 reporting, to be
extended with "Maven 3.0 support", then "Maven 3.1 support" and is just
collecting debt.

This library, if you look at it now, is anemic and is merely a "wrapper"
around Resolver classes, uses ancient stuff (read Maven2 classes) and
patterns, like misuse of ProjectBuildingRequest (same pattern as in ill
fated MAT), uses deprecated ArtifactRepository class for all kind of stuff
(hello split repository -- not possible to be used with these). In short,
this project does not offer any (new, not available) functionality, while
in turn, hinders and pushes for deprecated stuff. These should cease to
exist.

In fact, many shared projects should be scrutinized and most probably
declared "deprecated", as most of them were born to support Maven2 to
Maven3 transition (or maybe Maven 3.0 to 3.1+ transition like MAT was),
while today they just hinder Maven3 to Maven4 change, as many of these
shared stuff in fact still pull Maven2 classes in play.


Thanks
T

Re: [VOTE] Release Apache Maven 4.0.0-beta-2

+1

But as we know today, this was really too early to call it "beta". We
discovered issues that may introduce API changes...

On Mon, May 13, 2024 at 7:41 PM Guillaume Nodet  wrote:

> I've cut another release after having fixed a bug in the consumer pom
> creation.
>
> This is a vote to release Apache Maven 4.0.0-beta-1.
>
> We solved 21 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=
> 12354392
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354392
> >
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MNG/issues
>
> Release candidates:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-beta-2/
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2117/
>
> Source release SHA512:
> - apache-maven-4.0.0-beta-1-src.zip
>
>
> 0dff19216028ed7ab15914795c62a2a3247b9f45daedfd0db88266edecf97f16c888c7aac501b6b2d9373e03c828e9ba30f9837cfaafd9a4f32b04fa0776e0d3
> - apache-maven-4.0.0-beta-1-src.tar.gz
>
>
> 04df9d340081fa5cc4c840fee4bbed0d65d2d622e9cdbc0a713438a104933485f22d31bf4b35ce695913b790cf10f11f8f31ce73e0a796debfe7fc99268d9701
>
> Staging site:
> https://maven.apache.org/ref/4-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> The vote is open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> 
> Guillaume Nodet
>

Re: Trying to test the reworked compiler plugin

Howdy,

maven-plugin-tools: We agreed with Guillaume to split it: instead of mvn4,
master will be "maven 4" and we will introduce a maven-3.x branch for
Maven3 support. Currently the master was meant to support both (maven3 and
maven4 plugins), but it proved problematic, hence the split. A plugin
cannot be both anyway, it is this or that hence the user can choose which
version, 3.x or 4.x wants to use.
plugin-testing: AFAIK, same stands here, due huge difference how those
operate (maven-core vs new maven API).

This is all yet to be done.

@Guillaume Nodet  ping

Thanks
T

On Sat, May 18, 2024 at 1:44 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello all
>
> I'm trying to run the tests on the reworked compiler plugin for Maven 4,
> but execution is having an issue with Maven dependency injection. Before
> to give more details, I would like to check if I'm up to date.
>
> Three months ago, I was told to use the following branches:
>
>   * Maven core from https://github.com/apache/maven
>   * Plugin tools from
> https://github.com/apache/maven-plugin-tools/pull/242
>   * Plugin testing from
> https://github.com/apache/maven-plugin-testing/pull/39
>   * Compiler from https://github.com/apache/maven-compiler-plugin/pull/147
>
> I have kept my "Maven core" clone up-to-date. Other pull requests seem
> to have no new commits, but the master branches on which they are based
> have been updated. I wanted to search if more up-to-date Maven 4
> branches exist somewhere else, but the situation is a bit confusing:
>
>   * There is "mvn4" branches on many plugin repositories, but they are 2
> years old. Would it be possible to either update them or delete them?
>   * I found no code other than above pull requests that I could identify
> as designed for Maven 4. If the above pull requests are not ready to
> be merged, would it be possible to turn them as branches on Maven
> repositories, possibly replacing the previous "mvn4" branches? The
> goal is to make easy to find the most up-to-date code.
>
> If the above pull requests are the most up-to-date code for Maven 4,
> would it be possible to update them to "4.0.0-beta-2"? I tried to do
> that on my side, but got some difficulties. First, it seems that the
> following changes must be applied on Maven core for making possible to
> compile the plugins:
>
>   *
> https://github.com/Geomatys/maven/commit/5165ca60a1b44cd2a376cd1bfe48f558a2cbd54f
>
> I have not created a pull request for the above because I'm not sure if
> I understood the issue correctly. Next, after changing the dependencies
> to "4.0.0-beta-3-SNAPSHOT", the build of "maven-plugin-testing-harness"
> has the following test failure:
>
> java.lang.IllegalArgumentException: session is null
> at org.apache.maven.internal.impl.Utils.cast(Utils.java:44)
> at
> org.apache.maven.internal.impl.InternalSession.from(InternalSession.java:45)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.(DefaultProjectBuilder.java:291)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:135)
> at
> org.apache.maven.plugin.testing.MojoRule.readMavenProject(MojoRule.java:276)
> at
> org.apache.maven.plugin.testing.MojoRule.lookupConfiguredMojo(MojoRule.java:296)
> at
> org.apache.maven.plugin.testing.MojoRuleTest.testLookupInitializedMojo(MojoRuleTest.java:165)
>
> The code producing the null value is:
>
> static InternalSession from(org.eclipse.aether.RepositorySystemSession
> session) {
>  return cast(InternalSession.class,
> session.getData().get(InternalSession.class), "session");
> }
>
> It seems related to the issue that I'm having with the compiler plugin,
> where the following annotated field:
>
> /**
>   * The current build session instance.
>   */
> @Inject
> protected Session session;
>
> Stay null during the test execution. Is there any advise about how to
> proceed? For me, the ideal would be to have the "mvn4" branches in at
> least "maven-plugin-tools", "apache/maven-plugin-testing" and
> "maven-compiler-plugin" replaced by up-to-date branches (I wlll take
> care of rebasing my work on an up-to-date compiler branch).
>
>  Thanks,
>
>  Martin
>
>

Re: [VOTE] Release Maven Indexer 7.1.3

2024-05-19 Thread Tamás Cservenák

+1

On Fri, May 17, 2024, 09:09 Tamás Cservenák  wrote:

> Howdy,
>
> We solved 8 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12354090
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MINDEXER/issues
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2118/
>
> Source release SHA512:
>
> 78ce43d62de64322110f22de896d14d89fa6d93815a24ca60cb7aa08895d0d672b24c8e567cd10fe2e62b9bfd266af8d03f450173c3035ffc202f7c0a441b4ca
>
> Staging site:
> https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven Reporting API version 4.0.0-M12

2024-05-19 Thread Tamás Cservenák

+1

On Fri, May 17, 2024, 22:21 Michael Osipov  wrote:

> Hi,
>
> IMPORTANT: This require the following staging repositories:
>
> * Maven Doxia 2.0.0-M12
>
> we solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12354656
>
> There is one issue left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-api
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2120/
>
> https://repository.apache.org/content/repositories/maven-2120/org/apache/maven/reporting/maven-reporting-api/4.0.0-M12/maven-reporting-api-4.0.0-M12-source-release.zip
>
> Source release checksum(s):
> maven-reporting-api-4.0.0-M12-source-release.zip
> sha512:
>
> 0ff6bef22ee6e444ad91d1c136afcdde1a07dfdc6507c89a1b90b1df3ccf784776bddacf46cd729f3951165ecb4cf910b39241f2a4a64fa3c7d331fce0c31e09
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-api-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 Doxia version 2.0.0-M12

2024-05-19 Thread Tamás Cservenák

+1

On Fri, May 17, 2024, 22:04 Michael Osipov  wrote:

> Hi,
>
> we solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12354683
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2119/
>
> https://repository.apache.org/content/repositories/maven-2119/org/apache/maven/doxia/doxia/2.0.0-M12/doxia-2.0.0-M12-source-release.zip
>
> Source release checksum(s):
> doxia-2.0.0-M12-source-release.zip
> sha512:
>
> a0b655ed4d300a1e7333f5202555829f62bb5bf31db4ec14978cf27a9379436f626a87ec39d43c2cded90edfbd570edb3d8c26d6b9ea6df5bd20e632ac487087
>
> Staging site:
> https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
>
> Guide to testing staged releases:
> http://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
>
>

[VOTE] Release Maven Indexer 7.1.3

2024-05-17 Thread Tamás Cservenák

Howdy,

We solved 8 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12354090

There are still some issues in JIRA:
https://issues.apache.org/jira/projects/MINDEXER/issues

Staging repository:
https://repository.apache.org/content/repositories/maven-2118/

Source release SHA512:
78ce43d62de64322110f22de896d14d89fa6d93815a24ca60cb7aa08895d0d672b24c8e567cd10fe2e62b9bfd266af8d03f450173c3035ffc202f7c0a441b4ca

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

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

Vote open for 72 hours.

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

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.14.0

2024-05-14 Thread Tamás Cservenák

+1

On Sun, May 12, 2024 at 10:41 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20fixVersion%20%3D%2012353840%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-analyzer
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2115/
>
> https://repository.apache.org/content/repositories/maven-2115/org/apache/maven/shared/maven-dependency-analyzer/1.14.0/maven-dependency-analyzer-1.14.0-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.14.0-source-release.zip - SHA-512 :
>
> 177624ae1f2cff0a05bd694a70f7e139f7cad79db63287644dfbf307cc5be09624202f2ff00f16125926a4614553065603eb61143f690bf38e347ff6b2d00282
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-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 Build cache extension 1.2.0

2024-05-11 Thread Tamás Cservenák

+1

On Thu, May 9, 2024, 02:43 Olivier Lamy  wrote:

> Hi,
> Vote for release of Apache Maven Build cache extension 1.2.0
> We fixed 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324820=12353957
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2114/
> Staged sources dist:
>
> https://repository.apache.org/content/repositories/maven-2114/org/apache/maven/extensions/maven-build-cache-extension/1.2.0/maven-build-cache-extension-1.2.0-source-release.zip
>
> sha512:
> bc1a4b84c4f21a73964d8f65c3d37e372dfa8fc6d64e13db3f2d7ff2111485b41eb6bd24872626597070fd28cdcb55e0702cf9a2f106bedc7ec1483fbcd2aeb2
>
> Staged website:
>
> https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
>
> Vote open for 72h
> [+1]
> [0]
> [-1]
>
> Cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Invoker version 3.3.0

2024-05-10 Thread Tamás Cservenák

+1

On Tue, May 7, 2024, 23:00 Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 12 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12351567
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-invoker
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2113/
>
> https://repository.apache.org/content/repositories/maven-2113/org/apache/maven/shared/maven-invoker/3.3.0/maven-invoker-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-invoker-3.3.0-source-release.zip - SHA-512 :
>
> 746c8a1dd96c193690ae76f15198ab173767e1e9f5621697e6f6b4e207e698428c79f4c84f049ff216ca9e454ad3ffa2b80756a21c4d7cac577dc526083d86e3
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-invoker-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: [DISCUSS] MDK, a Maven Plugin SPI example

2024-05-09 Thread Tamás Cservenák

Howdy,

Did anyone look at or maybe even tried MDK?

Thanks
T

On Mon, May 6, 2024 at 4:36 PM Tamás Cservenák  wrote:

> Howdy,
>
> Please take a peek at (and maybe try out) latest Maveniverse project, MDK:
>
> https://github.com/maveniverse/mdk
>
> This is like "proof of concept" or "demo" of what the Plugin SPI pattern
> would be able to do.
>
> The idea is to broaden the support, and provide services even like
> "overlaid staging", when staging would receive deployments from multiple
> different sources (like for example OS native binaries).
>
> MDK is not yet, but will be integrated with Toolbox, to use it's sink
> abstraction:
> https://github.com/maveniverse/toolbox
>
> Have fun
> T
>

Re: Sisu Plexus release?

2024-05-08 Thread Tamás Cservenák

Howdy,

Olivier, I find this quite interesting, that according to you doing an
Eclipse release (even M one) is "just push a few buttons and run
something for a minute".
On the other hand, on Slack you educate Christoph about the "Apache way".
Please calm down and remain respectful.

Your PR [1] has been reviewed by Sisu project lead (Stuart McCulloch) and
is merged. All is fine.

The problem is in the "release must happen RIGHT NOW" stance of yours (for
whatever reason).
No Sisu committer will or can throw away everything they currently do (or
planned to do), just to make Sisu release happen, as you ask for it.
We are doing our best, and release for sure will happen soonish, as there
are several merged, but also several ongoing changes to be done yet (see
open PRs).

[1] https://github.com/eclipse/sisu.plexus/pull/52

On Wed, May 8, 2024 at 7:55 AM Christoph Läubrich 
wrote:

> Hi Olivier,
>
> I'm not 100% sure about the sisu[1] problem at Eclipse BUT usually there
> is no need for a vote or similar but from tiem to time there is a
> release or progress review. If I look here
> https://projects.eclipse.org/projects/technology.sisu/who you have 100%
> commits over the last three month, so it would make sense that @Konrad
> Windszus or @cstamas simply start a committer vote to make you a
> committer of the project, after that I would (if Stuart is non
> responsive anymore) start a Project Lead election for either any of you,
> at that point you then can do what ever is required (even though any
> committer can technically perform a release or ask for a release review
> some actions might require a Project Lead approval e.g. pushing to
> central), if you have any questions regarding Eclipse process you can
> ask the Eclipse EMO (e...@eclipse.org added as CC).
>
> If you need any help I can offer to give some help from my experience in
> other Eclipse Projects, at a first glance looking at the release page[1]
> a release review seems overdue but I'm not an expert on this specific
> topic, it just wont hurt to schedule one just to be sure.
>
> HTH
> Christoph
>
> [1] https://projects.eclipse.org/projects/technology.sisu
> [2] https://projects.eclipse.org/projects/technology.sisu/governance
>
> Am 07.05.24 um 23:23 schrieb Olivier Lamy:
> > Hi,
> > Sure but as a long-term developer, I cannot release this plexus part
> anymore.
> > It used to be very easy to release this major part of the system (but
> > for some reason this has been moved somewhere else. not something to
> > discuss again, of course)
> > I have been asking sisu dev mailing list for a release, but no answer
> yet.
> > I have been looking at this project mailing list archive.
> > There is an email about a possible process
> > (https://www.eclipse.org/lists/sisu-dev/msg00116.html), but as far as
> > I can see, this 0.9.0.M2 release has been done without any voting
> > process etc.
> > So releasing looks to be only a matter of having a few minutes to run
> > m-release-p and publish. (being contributor to another Eclipse
> > project, I cannot see anything with vote mandatory).
> >
> > If it's easier we can certainly move this sisu plexus project back to
> > where it was few years ago under the groupId org.codehaus.plexus and
> > releasing will not be a problem for maven contributors.
> >
> > regards
> > Olivier
> >
> >
> > On Mon, 6 May 2024 at 20:16, Tamás Cservenák 
> wrote:
> >>
> >> Btw, I feel really strange to have to explain to a long term maven
> >> contributor, that he can do maven release whenever he feels so
> >>
> >> T
> >>
> >> On Mon, May 6, 2024 at 11:59 AM Tamás Cservenák 
> wrote:
> >>
> >>> Howdy,
> >>>
> >>> I think you reversed the question... 3.9.7 was done and ready to go
> until
> >>> you stepped in.
> >>>
> >>> IMHO the real question is:
> >>> Is your issue (using overloaded methods in mojo config) really so
> urgent
> >>> to halt 3.9.7 release?
> >>> What is the problem with doing 3.9.8 maybe even two weeks later?
> >>>
> >>>
> >>> Thanks
> >>> T
> >>>
> >>> On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:
> >>>
> >>>> Is 3.9.7 really so urgent?
> >>>> Maybe we can wait a couple of days.
> >>>> I have been asking the sisu dev mailing list for a release.
> >>>> This should not be too long.
> >>>> I can see you are in the committers list
> >>>> (https://projects.eclipse.org/projects/technology.s

Re: [DISCUSS] MDK, a Maven Plugin SPI example

>
>
> Well, for *existing* core component I don't see an issue to add a toggle to
> say "deploy at end".
> What can be an issue there is only to make it global for the session and
> not per artifact + how to define "end" - agree onSessionClose can be too
> late but sure we can find a good "phase" (plain english not maven phases).
>

Which *existing* core component deploys today in Maven?
"At Maven Session end" (and no errors happened) is pretty good plain
english for me.


>
> I understand you only talk about artifact but makes years it is no more
> what maven trigger as deployment and we don't have much issue with current
> solution but we have with combined ones and making it using a different
> lifecycle will make it even harder to handle, in particular with shared
> components where lifecycle is no more what is in the pom and therefore you
> don't control it properly anymore from the pom.
> Feels like regressing 10 years ago in terms of solution covering for me.
>

Nobody mentioned a different lifecycle, only you.
MDK is totally the opposite of what you write...
Current m-deploy-p solution (the one you consider "good") is unchanged
since Maven 2.x, so unsure what regressing you talk about.
To be precise, is unchanged since 18 years, so 10 years sounds quite good,
no? (a joke)


> I have no idea what you target with your block about sonatype, users are
> covered by sonatype (both solutions btw at the cost of some jvm.config and
> deps for the oldest).
>

Does not sound to me like what you say stands:
https://lists.apache.org/thread/6t95xpkgjpxooljf613xf1853qrfv7yq

I don't feel "covered", sorry. Also, remember that (old) nx-staging-m-p
already broke once in Maven 3.9.x span.


> To be honest, today - and I never said it will not change ;), I don't care
> much of MDK but more about adding a concept we don't need and which will
> create new issues in maven so let's try to use one of the existing
> solutions maybe before moving to building a new maven - or discuss
> rebuilding maven from scratch if that is the ultimate intent, if we break
> the compat rule a lot of things can change and concepts can be
> simplified+refined but AFAIK we are not in this mood, are we?
>
>
You do it again: which "new concept" is added exactly by MDK?
(as everything else works based on existing and proven patterns).

T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

And few more things:
- my intent is to target BOTH, Maven3 and Maven4, as when Sonatype
deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also
Maven4) users are doomed to "roll their own" solutions for Central
publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF repo)
can work to a certain degree with m-deploy-p (at the "cost" of logging in
to the UI, and pressing Close button on auto-created staging repository),
the new Central Portal will not work with it (as it seems from doco). IMHO,
we cannot leave Maven3 users behind, we cannot afford to leave Maven3 users
without any solution.
- MDK like solution could also provide support in cases like this (my next
task on radar):
https://lists.apache.org/thread/j3r4hvoonx6ftl8vlgs0fo4f2z9pmll5
- and finally, nothing forces you to use MDK, obviously. If you publish OCI
images or beam up little green people with Maven, you do not have to use
it! Solution is opt-in, that IS one of the key points of MDK :)

But to have ANY progress on ANY of this:
- the plugin SPIs needs to be created/released
- we need to use SPIs in plugins
- and only then we can provide seamless experience to our users


T


On Mon, May 6, 2024 at 8:24 PM Tamás Cservenák  wrote:

>
>> If you don't need to create a new module nor any new interface in maven
>> core or a shared module I'm all for the change, otherwise it is a new
>> shared thing whatever you present it.
>>
>
> So, if we don't change anything, you accept the "change"? :)
>
> In short: MDK is just a "tech demo", but the "real stuff" is:
> * introduce SPIs for targeted o.a.m.p plugins (the proposed ones are
> deploy and gpg plugins)
> * modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and m-gpg-p)
> * and from that moment on, we have an "open for all" game in play, as MDK
> becomes really 'just one' solution.
> In fact, IMHO it is the Maven project itself that should be the home of
> something like MDK.
> Again, MDK is "just a tech demo".
>
>
>> I understand what you mean but it is the case of the "current" solution.
>> We don't need a new module nor anything outside plugins scope.
>> The "do at end" on maven built-in components is even a pretty bad example
>> cause it would be saner for the goal you describe to add a parameter on
>> maven components methods more than a new concept IMHO - concretely enable
>> this feature in repositorySystem directly which is already shared by
>> design.
>>
>
> This is the case where I'd like to _improve the current solution_ (as
> opposed to "this is what it is, live with it") as I personally am not
> satisfied with it.
> Each provider has its own plugin and "recipe", that you must
> adapt/incorporate (and pray it will not break with the following Maven
> release), and so on and so on.
> Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core always
> worked like this, all I did was just documented it and created
> a proof-of-concept (MDK).
> Repository system has no notion of "at (maven) session end", but it does
> have "on session close" (which is happening way-way later).
> We discussed it and also rejected deploying at "on session end", we've
> been already there: https://github.com/apache/maven-resolver/pull/437
>
>
>>
>> As soon as you make a plugin "living" more than its execution you are no
>> more "dead simple" and have a ton of edge cases as the one you mentionned
>> which is a simple one where both cases can make sense (don't deploy if the
>> test fail or let it be deployed - depends if you release or dev, close to
>> "fail test at end").
>> If you take the deploy jar + oci container case, the recover case is not
>> trivial, the "deploy at end" is just a broken concept by design and
>> requires something different to recover.
>>
>> What I mean is that we cover way enough cases without adding a new thing
>> in
>> core and that moving just one step further is not sufficient in most cases
>> so the solution will be complex for a poor concrete gain so we should
>> probably look for something else - but I agree covering it completely is
>> quite more challenging cause either you can embrace reproducible builds
>> and
>> upsert/get-and-update or you have to burn a version (snapshot or not) if
>> you can't recover manually.
>>
>
> Again, IMHO you miss the point: m-deploy-p is not "living" more than
> execution (but, is NOT replaced either!). Quite the opposite!
> It works 'as before', and is really just like a "messenger". It does all
> and accordi

Re: [DISCUSS] MDK, a Maven Plugin SPI example

>
>
> If you don't need to create a new module nor any new interface in maven
> core or a shared module I'm all for the change, otherwise it is a new
> shared thing whatever you present it.
>

So, if we don't change anything, you accept the "change"? :)

In short: MDK is just a "tech demo", but the "real stuff" is:
* introduce SPIs for targeted o.a.m.p plugins (the proposed ones are deploy
and gpg plugins)
* modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and m-gpg-p)
* and from that moment on, we have an "open for all" game in play, as MDK
becomes really 'just one' solution.
In fact, IMHO it is the Maven project itself that should be the home of
something like MDK.
Again, MDK is "just a tech demo".


> I understand what you mean but it is the case of the "current" solution.
> We don't need a new module nor anything outside plugins scope.
> The "do at end" on maven built-in components is even a pretty bad example
> cause it would be saner for the goal you describe to add a parameter on
> maven components methods more than a new concept IMHO - concretely enable
> this feature in repositorySystem directly which is already shared by
> design.
>

This is the case where I'd like to _improve the current solution_ (as
opposed to "this is what it is, live with it") as I personally am not
satisfied with it.
Each provider has its own plugin and "recipe", that you must
adapt/incorporate (and pray it will not break with the following Maven
release), and so on and so on.
Hence the MDK demo and SPI pattern idea. Nothing new, as Maven Core always
worked like this, all I did was just documented it and created
a proof-of-concept (MDK).
Repository system has no notion of "at (maven) session end", but it does
have "on session close" (which is happening way-way later).
We discussed it and also rejected deploying at "on session end", we've been
already there: https://github.com/apache/maven-resolver/pull/437


>
> As soon as you make a plugin "living" more than its execution you are no
> more "dead simple" and have a ton of edge cases as the one you mentionned
> which is a simple one where both cases can make sense (don't deploy if the
> test fail or let it be deployed - depends if you release or dev, close to
> "fail test at end").
> If you take the deploy jar + oci container case, the recover case is not
> trivial, the "deploy at end" is just a broken concept by design and
> requires something different to recover.
>
> What I mean is that we cover way enough cases without adding a new thing in
> core and that moving just one step further is not sufficient in most cases
> so the solution will be complex for a poor concrete gain so we should
> probably look for something else - but I agree covering it completely is
> quite more challenging cause either you can embrace reproducible builds and
> upsert/get-and-update or you have to burn a version (snapshot or not) if
> you can't recover manually.
>

Again, IMHO you miss the point: m-deploy-p is not "living" more than
execution (but, is NOT replaced either!). Quite the opposite!
It works 'as before', and is really just like a "messenger". It does all
and according to its config, and lives ONLY thru mojo execution.
Unsure what you are aiming it with 'make a plugin "living" more than its
execution' as none of that is happening here. Sigh.

I heard for the first time that "deploy at end" is a broken concept. I have
to strongly disagree here
(and I am talking about Maven Artifact deployments, and I did talk
about that ONLY, all the time. It is you who brought up OCI registry, not
me)



> No what you look at is "only artifacts deployment done my way", but it
> breaks all the cases maven deploys something else - and once again it is
> not rare today.
>
>
Again, I _did_ talk all the time about "Maven artifact deployment"
(I thought it was clear, as if you look at SPI, you see Resolver classes.
You did look at sources, right?)
You can always bring up any example, like OCI containers, or little green
men or whatever,
but how does any of that come here?

T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

Howdy,

inline.


Exactly...this is what will always happen with plugins and extensions.
> Indeed you can add a phase after plugins then you moved the issue to one
> more step but the issue is still *exactly* the same but in a new concept
> and layer, so literally no gain there.
>

This is not a new concept at all, one of the main reasons a lifecycle
participant was added was exactly this,
and the Takari lifecycle did leverage it for years. Unsure why this is a
"new concept" for you.



> No issue there, you still control the reactor and therefore control the
> last module built after all others if you want - I use that for the
> documentation module of a 100+ modules project, so not an issue, you can
> always have your last module have m-d-p.
>
>
But that's the point! I don't want to author an Ant-like Maven build!
I don't want to fiddle with each nit. I don't want to "fit carefully"
sticks, tricks and hacks, build a house of cards or Jenga-build.
I don't want to modify my build to "make it work". I don't want to adapt
extra hoops and loops in my build "make it happen".
I don't want "smart" and "intelligent" solutions. I don't want to check out
a Maven project and spend time figuring out "how it works".

I want simple wooden-wedge level solutions. I am in a "Dead Simple Maven
Builds" camp.



> Not sure what you meant there but I don't see any mutilation:
>
> * you want to control more your lifecycle -> you can, indeed it requires
> some configuration since it breaks the default setup but it is doable and
> main case is still smooth (convention over config)
> * you want to plug a custom impl in a plugin -> you can (Guillaume even did
> the work for extensions)
> * you want to make plugins working altogether sharing a coupled or loosely
> coupled state? -> you can (using an extension to hold it or a generic
> JVM/Maven type in the session data)
>
> So there is not yet any describe use case requiring a new concept in maven
> AFAIK.
>

Explained above what I mean by "mutilation".

But you can enumerate all the things you want, but still miss the point :)
Again, this is not a "new tech" or anything, not a "revolutionary solution"
for anything.
This is IMHO "deployment done right" (and more to come).

Oh yes, and this thread is about MDK.

Thanks
T

Re: [DISCUSS] MDK, a Maven Plugin SPI example

Romain,

I have more and more the feeling that you are not reading what has been
written down, at least not carefully enough.

Otherwise, you';d know that is it NOT "already doable", as explained in MDK
doco (but also in previous thread):
Just one example: the current "deploy at end" feature of m-deploy-p does
NOT deploy "at (build) end", but at "last module using m-deploy-p plugin".
Hence, you can end up with deployment done, and afterwards a build failure.
For example some latter module running tests that use non-standard
packaging and not using m-deploy-p on purpose.

Second, again as explained, the point is to NOT mutilate your build with
hoops and loops, adapt to chosen build service,
as if you choose (or you are forced) to move to another service, you would
need to rinse-repeat, but this time for the other publishing service.

Thanks
T

On Mon, May 6, 2024 at 5:56 PM Romain Manni-Bucau 
wrote:

> Hi Tamas
>
> So it is just a spi consommable from a plugin using an extension to share a
> state accross mojo execution...so nothing we already do.
>
> My understanding of your request is to bring to maven 4 api this concept
> for common needs (delayed tasks I'd say more than anything specific to
> deployment).
>
> But presented as in the wiki value stays quite low  cause it is already
> doable either with or without an extension - using the session and a plugin
> running at the end of the build.
>
> Le lun. 6 mai 2024 à 18:37, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > Please take a peek at (and maybe try out) latest Maveniverse project,
> MDK:
> >
> > https://github.com/maveniverse/mdk
> >
> > This is like "proof of concept" or "demo" of what the Plugin SPI pattern
> > would be able to do.
> >
> > The idea is to broaden the support, and provide services even like
> > "overlaid staging", when staging would receive deployments from multiple
> > different sources (like for example OS native binaries).
> >
> > MDK is not yet, but will be integrated with Toolbox, to use it's sink
> > abstraction:
> > https://github.com/maveniverse/toolbox
> >
> > Have fun
> > T
> >
>

[DISCUSS] MDK, a Maven Plugin SPI example

Howdy,

Please take a peek at (and maybe try out) latest Maveniverse project, MDK:

https://github.com/maveniverse/mdk

This is like "proof of concept" or "demo" of what the Plugin SPI pattern
would be able to do.

The idea is to broaden the support, and provide services even like
"overlaid staging", when staging would receive deployments from multiple
different sources (like for example OS native binaries).

MDK is not yet, but will be integrated with Toolbox, to use it's sink
abstraction:
https://github.com/maveniverse/toolbox

Have fun
T

Re: [DISCUSS] Maven Plugin SPI

This is IMHO not "great and powerful" but "dangerous and sneaky" option...

For starters, assume the user build fails with an error "failure in mojo
Foo", opens his POM, and will have no idea what mojo Foo is, as it is _not
even there_ (magic!)...

Second, you can _replace_ but not _extend_ existing plugin with this hack.
For example if you want to add 3rd feature (to existing 2 features of some
plugin), then your "replacement" plugin that is injected instead of the
original, would need to _reimplement_ (copy pasta?) the 2 features. I find
this redundant and plain wrong.

Third, I don't think that any of these solutions you mention implement the
SPI pattern, that this thread IS about.

T




On Mon, May 6, 2024 at 4:07 PM Romain Manni-Bucau 
wrote:

> Le lun. 6 mai 2024 à 16:00, Tamás Cservenák  a écrit
> :
>
> > Romain,
> >
> > for start, you are referring to a solution to "mangle the model after it
> > was read up". This is what nexus-staging-m-p does and I consider it wrong
> > and possibly illegal (despite the fact that I wrote that plugin).
> >
>
> I disagree, this was our choice and this is a great and powerful option.
> Moreover I think it is way more wrong to redo a solution which is already
> done cause of the mess in the code but also the comm it creates.
>
>
> > This is not a future proof way to do it. To be precise, nx-staging-m-p
> > injects m-deploy-p config (to become skipped), and also injects itself
> > (deploy) goal to become "Caliph instead of Caliph" (to deploy instead of
> > m-deploy-p) (ref  https://en.wikipedia.org/wiki/Iznogoud)
> >
>
> Rightwhich is great.
> We do the same in junit-platform plugin for goods.
>
>
> >
> > Other than that, I see no way how you could "alter" m-deploy-p behaviour
> > using this technique, as:
> > - here you can rewrite the POM
> > - rewrite plugin config
> > - but you cannot add/replace components from the plugin itself
> > - you CAN do what nx-staging does (remote/disable it, and inject
> yourself,
> > but again, I find this bad practice)
> >
> > Last bullet is a hack, I hope we both agree on this.
> >
>
> Right but you spoke about creating spi so explicitly enabling the N-1 point
> (injecting a component in configuration)so we are covered for all cases
> already.
> If you want an auto-discovered case you don't cover the case you describe,
> ie enable/disable deployAtEnd so I still don't see any issue for now.
>
>
> >
> > T
> >
> > T
> >
> > On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau  >
> > wrote:
> >
> > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
> > > afterProjectsRead sorry
> > >
> > > So long story short you have a clean way to handle SPI from plugins
> with
> > > explicit configuration from the pom or transversally from an extension.
> > > I don't see a case in between since user is not able to consume it.
> > >
> > > 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 lun. 6 mai 2024 à 15:48, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Romain,
> > > >
> > > > could you elaborate what you mean by this:
> > > > "At startup it does not need to be there, so there is no issue there
> > > while
> > > > you resolve the plugin dependency you inject from the extension in
> > > > afterModelRead normally."
> > > >
> > > > What is "afterModelRead"?
> > > >
> > > > T
> > > >
> > > >
> > > > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Tamas, the extension can inject the configuration which is
> > instantiated
> > > > > when the mojo will be executed.
> > > > > At startup it does not need to be there, so there is no issue there
> > > while
> > > &

Re: [DISCUSS] Maven Plugin SPI

Romain,

for start, you are referring to a solution to "mangle the model after it
was read up". This is what nexus-staging-m-p does and I consider it wrong
and possibly illegal (despite the fact that I wrote that plugin).
This is not a future proof way to do it. To be precise, nx-staging-m-p
injects m-deploy-p config (to become skipped), and also injects itself
(deploy) goal to become "Caliph instead of Caliph" (to deploy instead of
m-deploy-p) (ref  https://en.wikipedia.org/wiki/Iznogoud)

Other than that, I see no way how you could "alter" m-deploy-p behaviour
using this technique, as:
- here you can rewrite the POM
- rewrite plugin config
- but you cannot add/replace components from the plugin itself
- you CAN do what nx-staging does (remote/disable it, and inject yourself,
but again, I find this bad practice)

Last bullet is a hack, I hope we both agree on this.

T

T

On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau 
wrote:

>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44
> afterProjectsRead sorry
>
> So long story short you have a clean way to handle SPI from plugins with
> explicit configuration from the pom or transversally from an extension.
> I don't see a case in between since user is not able to consume it.
>
> 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 lun. 6 mai 2024 à 15:48, Tamás Cservenák  a écrit
> :
>
> > Romain,
> >
> > could you elaborate what you mean by this:
> > "At startup it does not need to be there, so there is no issue there
> while
> > you resolve the plugin dependency you inject from the extension in
> > afterModelRead normally."
> >
> > What is "afterModelRead"?
> >
> > T
> >
> >
> > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Tamas, the extension can inject the configuration which is instantiated
> > > when the mojo will be executed.
> > > At startup it does not need to be there, so there is no issue there
> while
> > > you resolve the plugin dependency you inject from the extension in
> > > afterModelRead normally.
> > >
> > > 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 lun. 6 mai 2024 à 15:36, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Laeubi,
> > > >
> > > > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> > > > examples?
> > > >
> > > > As in case of Maven (proper, so "vanilla"), core extension is loaded
> > > first
> > > > (early), that would like to define SPI implementations, but the
> plugin
> > > that
> > > > would carry SPI interfaces, if SPI would be within plugin as
> proposed,
> > is
> > > > "yet to be seen", will be loaded by mvn core on first encounter in
> > > > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > > > classloaders, again defunct.
> > > >
> > > > And yes, this solution would enable -- depending on SPI -- to extend
> > > > existing SPI enabled-plugin in various ways, without touching the
> > > > build/POMs itself.
> > > >
> > > >
> > > > T
> > > >
> > > >
> > > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich <
> m...@laeubi-soft.de
> > >
> > > > wrote:
> > > >
> > > > > Hi Tamas,
> > > > >
> > > > > I'm specifically asking because Tycho has already a plugin-spi
> > support
> > > > > we use to a great extent, so if there would be a general usable
> > > solution
> > > > > that would be great I even asked

Re: [DISCUSS] Maven Plugin SPI

Romain,

could you elaborate what you mean by this:
"At startup it does not need to be there, so there is no issue there while
you resolve the plugin dependency you inject from the extension in
afterModelRead normally."

What is "afterModelRead"?

T


On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau 
wrote:

> Tamas, the extension can inject the configuration which is instantiated
> when the mojo will be executed.
> At startup it does not need to be there, so there is no issue there while
> you resolve the plugin dependency you inject from the extension in
> afterModelRead normally.
>
> 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 lun. 6 mai 2024 à 15:36, Tamás Cservenák  a écrit
> :
>
> > Laeubi,
> >
> > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
> > examples?
> >
> > As in case of Maven (proper, so "vanilla"), core extension is loaded
> first
> > (early), that would like to define SPI implementations, but the plugin
> that
> > would carry SPI interfaces, if SPI would be within plugin as proposed, is
> > "yet to be seen", will be loaded by mvn core on first encounter in
> > lifecycle. Or, if both load SPI interfaces, they will end up in two
> > classloaders, again defunct.
> >
> > And yes, this solution would enable -- depending on SPI -- to extend
> > existing SPI enabled-plugin in various ways, without touching the
> > build/POMs itself.
> >
> >
> > T
> >
> >
> > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich 
> > wrote:
> >
> > > Hi Tamas,
> > >
> > > I'm specifically asking because Tycho has already a plugin-spi support
> > > we use to a great extent, so if there would be a general usable
> solution
> > > that would be great I even asked many times for it but always got "use
> > > an extension" so I wonder what changed the mind of maven-devs or if it
> > > will be just another thing exclusive to "maven-core-plugins" or can
> > > other reuse that (how?). And if others can reuse it, why have a
> > > dedicated repository and not use the repository of the plugin that
> > > offers the spi?
> > >
> > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > > > Howdy,
> > > >
> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > >
> > > > This repository would hold SPIs as explained here
> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > >
> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > >
> > > > For now, we have two candidates to apply SPI pattern:
> > > > * maven-deploy-plugin (yet to be added)
> > > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> > not
> > > > follow pattern from wiki)
> > > >
> > > > Example GAs:
> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Maven Plugin SPI

Laeubi,

How does tycho use plugin-spi? Can you show me some Tycho plugin-spi
examples?

As in case of Maven (proper, so "vanilla"), core extension is loaded first
(early), that would like to define SPI implementations, but the plugin that
would carry SPI interfaces, if SPI would be within plugin as proposed, is
"yet to be seen", will be loaded by mvn core on first encounter in
lifecycle. Or, if both load SPI interfaces, they will end up in two
classloaders, again defunct.

And yes, this solution would enable -- depending on SPI -- to extend
existing SPI enabled-plugin in various ways, without touching the
build/POMs itself.

T

On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich 
wrote:

> Hi Tamas,
>
> I'm specifically asking because Tycho has already a plugin-spi support
> we use to a great extent, so if there would be a general usable solution
> that would be great I even asked many times for it but always got "use
> an extension" so I wonder what changed the mind of maven-devs or if it
> will be just another thing exclusive to "maven-core-plugins" or can
> other reuse that (how?). And if others can reuse it, why have a
> dedicated repository and not use the repository of the plugin that
> offers the spi?
>
> Am 06.05.24 um 14:08 schrieb Tamás Cservenák:
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Plugin SPI

Sure,

Again, I am fine with having SPI artifact next to plugin consumer artifact.
All I wanted to prevent is having tens or more versions of SPI artifact
released, while in fact they are "same thing".

T

On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet  wrote:

> Le lun. 6 mai 2024 à 14:38, Tamás Cservenák  a écrit
> :
>
> > lapsus: as in maven-core and maven-model SHOULD NOT share the same
> release
> > lifecycle. They DO currently.
> > Which implies that we have as many maven-model artifacts released so far
> as
> > many maven, but many of them are binary equivalent to each other.
> >
>
> What's the drawback with that ? It's much easier to handle for both the
> developper side
> and for the consumer side (they only have to upgrade a single version
> instead of two).
>
> I'm quite on the opposite side, and I'd much rather simplify our release
> cycles rather
> than going with one repo per jar...
>
>
> > That's all I wanted to prevent. Am fine with having SPI next to the
> plugin
> > as well...
> >
> > T
> >
> > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák 
> > wrote:
> >
> > > Pretty much the same story as Maven models vs Maven "core" (maven-core
> in
> > > 3.x or api-imple in 4) they don't share the same release lifecycle.
> > >
> > > SPI is not to be changed often, while we do patch releases of the
> > plugins.
> > > Am not saying we cannot keep SPI along with Plugins, I am just saying
> > that
> > > it's pointless: we will have many releases of the same thing.
> > >
> > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet 
> > wrote:
> > >
> > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
> > >> écrit :
> > >>
> > >> > Howdy,
> > >> >
> > >> > IIUC you have a problem with designated G?
> > >> > As if so, that is really irrelevant. Point is that SPI cannot reside
> > >> with
> > >> > Plugin, as they share totally different release cycles.
> > >> >
> > >>
> > >> Why ?
> > >>
> > >>
> > >> >
> > >> > Second, you mention a plugin dep, that is hence available in the
> same
> > >> scope
> > >> > as the plugin itself...  which is obviously not enough in some
> cases.
> > >> >
> > >> > T
> > >> >
> > >> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi Tamas,
> > >> > >
> > >> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes
> > >> sense
> > >> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > >> > > My understanding is that we already have that since any plugin can
> > >> > define a
> > >> > > specific SPI in its code and get it injected from a plugin dep
> using
> > >> its
> > >> > >  block - exactly like shade plugin references its
> > >> > > transformers to be concrete.
> > >> > > So for me nothing to create nor modify to get an old feature.
> > >> > >
> > >> > > 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák 
> a
> > >> > écrit
> > >> > > :
> > >> > >
> > >> > > > Howdy,
> > >> > > >
> > >> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > >> > > >
> > >> > > > This repository would hold SPIs as explained here
> > >> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > >> > > >
> > >> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > >> > > >
> > >> > > > For now, we have two candidates to apply SPI pattern:
> > >> > > > * maven-deploy-plugin (yet to be added)
> > >> > > > * maven-gpg-plugin (already have it, but in unusable form, as it
> > >> does
> > >> > not
> > >> > > > follow pattern from wiki)
> > >> > > >
> > >> > > > Example GAs:
> > >> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > >> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > >> > > >
> > >> > > > Thanks
> > >> > > > T
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >> 
> > >> Guillaume Nodet
> > >>
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven Plugin SPI

Romain,

one more thing I missed to respond: you say
"plugin can define a specific SPI in its code and get it injected from a
plugin dep using its  block"

A) I hope you meant here "get it injected from a plugin dep using its
 block" :)
Since as we know, doing trickeries like using  block to set
GAV-like things, that plugin resolves on its own is BAD THING to do: Maven
itself have no knowledge about such dependencies, and it totally breaks
reactor builds, where same thing is being built, and later used as "tricky
dependency". This pattern is bad as it is.

B) If defined as , then -- obviously -- the dependency
components will share the same plugin scope, so you are still in a very
"narrow" scope, as none of the mentioned plugins are _usually_ set up as
extensions (deploy, gpg). Moreover, remember the "early deploy at end"
implementation, that required m-deploy-p to be made into extension to make
the feature work... it just caused a ton of confusion to users.

T

On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> My understanding is that we already have that since any plugin can define a
> specific SPI in its code and get it injected from a plugin dep using its
>  block - exactly like shade plugin references its
> transformers to be concrete.
> So for me nothing to create nor modify to get an old feature.
>
> 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Maven Plugin SPI

lapsus: as in maven-core and maven-model SHOULD NOT share the same release
lifecycle. They DO currently.
Which implies that we have as many maven-model artifacts released so far as
many maven, but many of them are binary equivalent to each other.
That's all I wanted to prevent. Am fine with having SPI next to the plugin
as well...

T

On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák  wrote:

> Pretty much the same story as Maven models vs Maven "core" (maven-core in
> 3.x or api-imple in 4) they don't share the same release lifecycle.
>
> SPI is not to be changed often, while we do patch releases of the plugins.
> Am not saying we cannot keep SPI along with Plugins, I am just saying that
> it's pointless: we will have many releases of the same thing.
>
> On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet  wrote:
>
>> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a
>> écrit :
>>
>> > Howdy,
>> >
>> > IIUC you have a problem with designated G?
>> > As if so, that is really irrelevant. Point is that SPI cannot reside
>> with
>> > Plugin, as they share totally different release cycles.
>> >
>>
>> Why ?
>>
>>
>> >
>> > Second, you mention a plugin dep, that is hence available in the same
>> scope
>> > as the plugin itself...  which is obviously not enough in some cases.
>> >
>> > T
>> >
>> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Hi Tamas,
>> > >
>> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes
>> sense
>> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
>> > > My understanding is that we already have that since any plugin can
>> > define a
>> > > specific SPI in its code and get it injected from a plugin dep using
>> its
>> > >  block - exactly like shade plugin references its
>> > > transformers to be concrete.
>> > > So for me nothing to create nor modify to get an old feature.
>> > >
>> > > 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
>> > écrit
>> > > :
>> > >
>> > > > Howdy,
>> > > >
>> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
>> > > >
>> > > > This repository would hold SPIs as explained here
>> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
>> > > >
>> > > > Designated G: "org.apache.maven.maven-plugin-spi"
>> > > >
>> > > > For now, we have two candidates to apply SPI pattern:
>> > > > * maven-deploy-plugin (yet to be added)
>> > > > * maven-gpg-plugin (already have it, but in unusable form, as it
>> does
>> > not
>> > > > follow pattern from wiki)
>> > > >
>> > > > Example GAs:
>> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
>> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
>> > > >
>> > > > Thanks
>> > > > T
>> > > >
>> > >
>> >
>>
>>
>> --
>> 
>> Guillaume Nodet
>>
>

Re: [DISCUSS] Maven Plugin SPI

Pretty much the same story as Maven models vs Maven "core" (maven-core in
3.x or api-imple in 4) they don't share the same release lifecycle.

SPI is not to be changed often, while we do patch releases of the plugins.
Am not saying we cannot keep SPI along with Plugins, I am just saying that
it's pointless: we will have many releases of the same thing.

On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet  wrote:

> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > IIUC you have a problem with designated G?
> > As if so, that is really irrelevant. Point is that SPI cannot reside with
> > Plugin, as they share totally different release cycles.
> >
>
> Why ?
>
>
> >
> > Second, you mention a plugin dep, that is hence available in the same
> scope
> > as the plugin itself...  which is obviously not enough in some cases.
> >
> > T
> >
> > On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Hi Tamas,
> > >
> > > I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> > > instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> > > My understanding is that we already have that since any plugin can
> > define a
> > > specific SPI in its code and get it injected from a plugin dep using
> its
> > >  block - exactly like shade plugin references its
> > > transformers to be concrete.
> > > So for me nothing to create nor modify to get an old feature.
> > >
> > > 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák  a
> > écrit
> > > :
> > >
> > > > Howdy,
> > > >
> > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> > > >
> > > > This repository would hold SPIs as explained here
> > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> > > >
> > > > Designated G: "org.apache.maven.maven-plugin-spi"
> > > >
> > > > For now, we have two candidates to apply SPI pattern:
> > > > * maven-deploy-plugin (yet to be added)
> > > > * maven-gpg-plugin (already have it, but in unusable form, as it does
> > not
> > > > follow pattern from wiki)
> > > >
> > > > Example GAs:
> > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven Plugin SPI

Howdy,

IIUC you have a problem with designated G?
As if so, that is really irrelevant. Point is that SPI cannot reside with
Plugin, as they share totally different release cycles.

Second, you mention a plugin dep, that is hence available in the same scope
as the plugin itself...  which is obviously not enough in some cases.

T

On Mon, May 6, 2024 at 2:25 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense
> instead of org.apache.maven.plugins.$pluginArtifact-spi ?
> My understanding is that we already have that since any plugin can define a
> specific SPI in its code and get it injected from a plugin dep using its
>  block - exactly like shade plugin references its
> transformers to be concrete.
> So for me nothing to create nor modify to get an old feature.
>
> 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > I'd like to create a new ASF Maven git repo "maven-plugin-spi".
> >
> > This repository would hold SPIs as explained here
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI
> >
> > Designated G: "org.apache.maven.maven-plugin-spi"
> >
> > For now, we have two candidates to apply SPI pattern:
> > * maven-deploy-plugin (yet to be added)
> > * maven-gpg-plugin (already have it, but in unusable form, as it does not
> > follow pattern from wiki)
> >
> > Example GAs:
> > org.apache.maven.maven-plugin-spi:maven-deploy-spi
> > org.apache.maven.maven-plugin-spi:maven-gpg-spi
> >
> > Thanks
> > T
> >
>

[DISCUSS] Maven Plugin SPI

Howdy,

I'd like to create a new ASF Maven git repo "maven-plugin-spi".

This repository would hold SPIs as explained here
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI

Designated G: "org.apache.maven.maven-plugin-spi"

For now, we have two candidates to apply SPI pattern:
* maven-deploy-plugin (yet to be added)
* maven-gpg-plugin (already have it, but in unusable form, as it does not
follow pattern from wiki)

Example GAs:
org.apache.maven.maven-plugin-spi:maven-deploy-spi
org.apache.maven.maven-plugin-spi:maven-gpg-spi

Thanks
T

Re: [DISCUSS] Maven3 and Maven4 support split

Romain,

You can look at this change (which I did, for plugin testing) just like
resolver-1.9.x branch: a "stable" release of testing for 3.x plugins is
very desperately needed.
Same thing for maven-plugin-plugin. So yes, this is kinda the b) option: a
Maven4 plugin cannot be built (m-p-p or tested m-p-t) with Maven3 tools and
Maven3.

As for doing this for plugins (all of them) is open for debate.

T



On Mon, May 6, 2024 at 12:31 PM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> If the impact is to prevent to build a maven 3 (original setup version or
> CI version for ex) with maven 4 (local version for ex) then I think it
> violates the contract we had for maven 4 and I'd really like it to not
> happen.
> If it is the opposite (a maven 4 based/native project can't be ran with
> maven 3) then +1.
> What I'd really don't want to see is to have to maintain 2 branches for all
> plugins for the coming ~5 years.
> If *really* an issue I'd prefer we write a migration project (openrewrite
> like - probably without openrewrite technically) to just write the maven 4
> project and make it maven 3 friendly automatically (can be a x-maven-plugin
> downloading x-v3 or x-v4 subartifact for the runtime, not sexy internally
> but very smooth in terms of usage).
>
> Best,
> 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 lun. 6 mai 2024 à 12:14, Tamás Cservenák  a écrit
> :
>
> > Howdy,
> >
> > my pain point was plugin-testing-harness 3.3.0 that is really ancient,
> > while master of it was mixing maven3 and maven4 support... so I went to
> > split things.
> >
> > IMO we need to split (like maven-3.x and master branch) for maven 3 and
> > maven 4 support, as there is really no need to support "both", as in case
> > of plugins, they are "this or that", they cannot be maven3 and maven4 at
> > the same time.
> >
> > Hence, I started with maven-plugin-testing:
> > https://github.com/apache/maven-plugin-testing/tree/maven-3.x
> >
> > Please eyeball and would like to prepare a 3.4.0 release of it soon.
> >
> > By the way, same should be done in maven-plugin-plugin (no need to
> support
> > creation of maven3 and maven4 plugins at the same time)... and maybe same
> > pattern (using branches maven-3.x and master for 3 and 4) should be
> applied
> > to all plugins?
> >
> > Thanks
> > T
> >
>

Re: Quo Vadis Maven?

Btw, I feel really strange to have to explain to a long term maven
contributor, that he can do maven release whenever he feels so

T

On Mon, May 6, 2024 at 11:59 AM Tamás Cservenák  wrote:

> Howdy,
>
> I think you reversed the question... 3.9.7 was done and ready to go until
> you stepped in.
>
> IMHO the real question is:
> Is your issue (using overloaded methods in mojo config) really so urgent
> to halt 3.9.7 release?
> What is the problem with doing 3.9.8 maybe even two weeks later?
>
>
> Thanks
> T
>
> On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:
>
>> Is 3.9.7 really so urgent?
>> Maybe we can wait a couple of days.
>> I have been asking the sisu dev mailing list for a release.
>> This should not be too long.
>> I can see you are in the committers list
>> (https://projects.eclipse.org/projects/technology.sisu/who) with
>> Konrad so maybe you can help to expedite this?
>>
>> regards
>> Olivier
>>
>>
>> On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
>> >
>> > Howdy,
>> >
>> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
>> fixes
>> > contributed by non committers.
>> >
>> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
>> > "stop and wait" for a bugfix, as we can always spin 3.9.8.
>> > Releases are cheap, and can be done whenever we (anyone of us) feels
>> right
>> > to do so...
>> >
>> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a
>> "now
>> > or never" situation. Just spin 3.9.8 whenever you think is ready.
>> >
>> > My 5 cents
>> > T
>> >
>> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
>> >
>> > > Hi
>> > > Can we please integrate
>> https://issues.apache.org/jira/browse/MNG-8116
>> > > The fix is ready and really simple.
>> > >
>> > > thanks
>> > > Olivier
>> > >
>> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
>> wrote:
>> > > >
>> > > > Howdy,
>> > > >
>> > > > This is just a short newsflash about upcoming planned releases
>> related to
>> > > > Maven.
>> > > >
>> > > > Recently we got a huge spike in plugin releases, with various fixes
>> and
>> > > > improvements. I will not enumerate all of them here, just use `mvn
>> > > > versions:display-plugin-updates` to pick them up ;)
>> > > > (and more plugins to come).
>> > > >
>> > > > What I do want to share is about our upcoming Maven releases...
>> > > >
>> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
>> important
>> > > > Resolver update and other important fixes. Most importantly, the
>> > > file-locks
>> > > > are getting nice improvement (feedback VERY welcome).
>> > > >
>> > > > Maven 3.9.7 issues:
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
>> > > >
>> > > > Resolver 1.9.19 issues (mostly bug fixes):
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
>> > > >
>> > > > At the same time, we plan to release Maven Daemon (m39) as well, to
>> have
>> > > it
>> > > > aligned with Maven 3,9,7: with many bug fixes and
>> improvements/alignments
>> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
>> > > > interchangeable on workstations.
>> > > >
>> > > > Next, Maven 4 is turning beta, so the next release will be beta1!
>> And
>> > > > again, same thing for Maven Damon (m40), we will have a release
>> that will
>> > > > include Maven 4 beta-1.
>> > > >
>> > > > Maven 4 beta-1
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
>> > > >
>> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
>> beta-1
>> > > > release):
>> > > >
>> > >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
>> > > >
>> > > > Keep your eyes on our upcoming releases,
>> > > > and have fun!
>> > > > - The Apache Maven team
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

[DISCUSS] Maven3 and Maven4 support split

Howdy,

my pain point was plugin-testing-harness 3.3.0 that is really ancient,
while master of it was mixing maven3 and maven4 support... so I went to
split things.

IMO we need to split (like maven-3.x and master branch) for maven 3 and
maven 4 support, as there is really no need to support "both", as in case
of plugins, they are "this or that", they cannot be maven3 and maven4 at
the same time.

Hence, I started with maven-plugin-testing:
https://github.com/apache/maven-plugin-testing/tree/maven-3.x

Please eyeball and would like to prepare a 3.4.0 release of it soon.

By the way, same should be done in maven-plugin-plugin (no need to support
creation of maven3 and maven4 plugins at the same time)... and maybe same
pattern (using branches maven-3.x and master for 3 and 4) should be applied
to all plugins?

Thanks
T

Re: Quo Vadis Maven?

Howdy,

I think you reversed the question... 3.9.7 was done and ready to go until
you stepped in.

IMHO the real question is:
Is your issue (using overloaded methods in mojo config) really so urgent to
halt 3.9.7 release?
What is the problem with doing 3.9.8 maybe even two weeks later?


Thanks
T

On Mon, May 6, 2024 at 7:45 AM Olivier Lamy  wrote:

> Is 3.9.7 really so urgent?
> Maybe we can wait a couple of days.
> I have been asking the sisu dev mailing list for a release.
> This should not be too long.
> I can see you are in the committers list
> (https://projects.eclipse.org/projects/technology.sisu/who) with
> Konrad so maybe you can help to expedite this?
>
> regards
> Olivier
>
>
> On Sun, 5 May 2024 at 21:05, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple
> fixes
> > contributed by non committers.
> >
> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
> > "stop and wait" for a bugfix, as we can always spin 3.9.8.
> > Releases are cheap, and can be done whenever we (anyone of us) feels
> right
> > to do so...
> >
> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now
> > or never" situation. Just spin 3.9.8 whenever you think is ready.
> >
> > My 5 cents
> > T
> >
> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:
> >
> > > Hi
> > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116
> > > The fix is ready and really simple.
> > >
> > > thanks
> > > Olivier
> > >
> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák 
> wrote:
> > > >
> > > > Howdy,
> > > >
> > > > This is just a short newsflash about upcoming planned releases
> related to
> > > > Maven.
> > > >
> > > > Recently we got a huge spike in plugin releases, with various fixes
> and
> > > > improvements. I will not enumerate all of them here, just use `mvn
> > > > versions:display-plugin-updates` to pick them up ;)
> > > > (and more plugins to come).
> > > >
> > > > What I do want to share is about our upcoming Maven releases...
> > > >
> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an
> important
> > > > Resolver update and other important fixes. Most importantly, the
> > > file-locks
> > > > are getting nice improvement (feedback VERY welcome).
> > > >
> > > > Maven 3.9.7 issues:
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> > > >
> > > > Resolver 1.9.19 issues (mostly bug fixes):
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> > > >
> > > > At the same time, we plan to release Maven Daemon (m39) as well, to
> have
> > > it
> > > > aligned with Maven 3,9,7: with many bug fixes and
> improvements/alignments
> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> > > > interchangeable on workstations.
> > > >
> > > > Next, Maven 4 is turning beta, so the next release will be beta1! And
> > > > again, same thing for Maven Damon (m40), we will have a release that
> will
> > > > include Maven 4 beta-1.
> > > >
> > > > Maven 4 beta-1
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> > > >
> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4
> beta-1
> > > > release):
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
> > > >
> > > > Keep your eyes on our upcoming releases,
> > > > and have fun!
> > > > - The Apache Maven team
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Quo Vadis Maven?

2024-05-05 Thread Tamás Cservenák

Howdy,

Maven 3.9.7 was ready to be released 3 days ago and contains multiple fixes
contributed by non committers.

MNG-8116 was added 2 days ago. I really see no reason to be blocked, to
"stop and wait" for a bugfix, as we can always spin 3.9.8.
Releases are cheap, and can be done whenever we (anyone of us) feels right
to do so...

3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now
or never" situation. Just spin 3.9.8 whenever you think is ready.

My 5 cents
T

On Sun, May 5, 2024 at 2:14 AM Olivier Lamy  wrote:

> Hi
> Can we please integrate https://issues.apache.org/jira/browse/MNG-8116
> The fix is ready and really simple.
>
> thanks
> Olivier
>
> On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > This is just a short newsflash about upcoming planned releases related to
> > Maven.
> >
> > Recently we got a huge spike in plugin releases, with various fixes and
> > improvements. I will not enumerate all of them here, just use `mvn
> > versions:display-plugin-updates` to pick them up ;)
> > (and more plugins to come).
> >
> > What I do want to share is about our upcoming Maven releases...
> >
> > Maven 3.9.7 is nearing (read: coming soon), and will have an important
> > Resolver update and other important fixes. Most importantly, the
> file-locks
> > are getting nice improvement (feedback VERY welcome).
> >
> > Maven 3.9.7 issues:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> >
> > Resolver 1.9.19 issues (mostly bug fixes):
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> >
> > At the same time, we plan to release Maven Daemon (m39) as well, to have
> it
> > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments
> > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> > interchangeable on workstations.
> >
> > Next, Maven 4 is turning beta, so the next release will be beta1! And
> > again, same thing for Maven Damon (m40), we will have a release that will
> > include Maven 4 beta-1.
> >
> > Maven 4 beta-1
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> >
> > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1
> > release):
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
> >
> > Keep your eyes on our upcoming releases,
> > and have fun!
> > - The Apache Maven team
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Plugin Tools version 3.13.0

2024-05-04 Thread Tamás Cservenák

+1

On Fri, May 3, 2024 at 8:57 AM Michael Osipov  wrote:

> Hi,
>
> we solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12354458
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2108/
>
> https://repository.apache.org/content/repositories/maven-2108/org/apache/maven/plugin-tools/maven-plugin-tools/3.13.0/maven-plugin-tools-3.13.0-source-release.zip
>
> Source release checksum(s):
> maven-plugin-tools-3.13.0-source-release.zip
> sha512:
>
> a572bd12b252a6794051277050dc1f9750f60f6ab06f097b3a26acd5de35b4a99c2796eb36b4faac6a9bb98a0d21c6df4a5c61f8f766f60e6af524c9bcb3211d
>
> 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 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: Quo Vadis Maven?

2024-05-04 Thread Tamás Cservenák

MNG-8041: I moved it out
MNG-8073: done, thanks to Sylwester and Slawek

T

On Fri, May 3, 2024 at 5:33 PM Tamás Cservenák  wrote:

> MNG-8041: can be moved out, needs a bit more verification
> MNG-8073: needs modello release, and can be done. but beta-2 is fine as
> well
>
> So IMHO both can be pushed to beta-2
>
> T
>
> On Fri, May 3, 2024 at 5:32 PM Guillaume Nodet  wrote:
>
>> I'd like to release beta-1 next week.
>> Maven Daemon is ready to be upgrade to it with
>> https://github.com/apache/maven-mvnd/pull/974
>>
>> Tamás, what's your plan regarding the two remaining issues:
>>  * https://issues.apache.org/jira/browse/MNG-8041
>>  * https://issues.apache.org/jira/browse/MNG-8073
>>
>> Cheers,
>> Guillaume
>>
>> Le mar. 23 avr. 2024 à 23:12, Tamás Cservenák  a
>> écrit :
>>
>> > Howdy,
>> >
>> > This is just a short newsflash about upcoming planned releases related
>> to
>> > Maven.
>> >
>> > Recently we got a huge spike in plugin releases, with various fixes and
>> > improvements. I will not enumerate all of them here, just use `mvn
>> > versions:display-plugin-updates` to pick them up ;)
>> > (and more plugins to come).
>> >
>> > What I do want to share is about our upcoming Maven releases...
>> >
>> > Maven 3.9.7 is nearing (read: coming soon), and will have an important
>> > Resolver update and other important fixes. Most importantly, the
>> file-locks
>> > are getting nice improvement (feedback VERY welcome).
>> >
>> > Maven 3.9.7 issues:
>> >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
>> >
>> > Resolver 1.9.19 issues (mostly bug fixes):
>> >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
>> >
>> > At the same time, we plan to release Maven Daemon (m39) as well, to
>> have it
>> > aligned with Maven 3,9,7: with many bug fixes and
>> improvements/alignments
>> > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
>> > interchangeable on workstations.
>> >
>> > Next, Maven 4 is turning beta, so the next release will be beta1! And
>> > again, same thing for Maven Damon (m40), we will have a release that
>> will
>> > include Maven 4 beta-1.
>> >
>> > Maven 4 beta-1
>> >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
>> >
>> > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1
>> > release):
>> >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
>> >
>> > Keep your eyes on our upcoming releases,
>> > and have fun!
>> > - The Apache Maven team
>> >
>>
>>
>> --
>> 
>> Guillaume Nodet
>>
>

Re: Quo Vadis Maven?

2024-05-03 Thread Tamás Cservenák

MNG-8041: can be moved out, needs a bit more verification
MNG-8073: needs modello release, and can be done. but beta-2 is fine as well

So IMHO both can be pushed to beta-2

T

On Fri, May 3, 2024 at 5:32 PM Guillaume Nodet  wrote:

> I'd like to release beta-1 next week.
> Maven Daemon is ready to be upgrade to it with
> https://github.com/apache/maven-mvnd/pull/974
>
> Tamás, what's your plan regarding the two remaining issues:
>  * https://issues.apache.org/jira/browse/MNG-8041
>  * https://issues.apache.org/jira/browse/MNG-8073
>
> Cheers,
> Guillaume
>
> Le mar. 23 avr. 2024 à 23:12, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > This is just a short newsflash about upcoming planned releases related to
> > Maven.
> >
> > Recently we got a huge spike in plugin releases, with various fixes and
> > improvements. I will not enumerate all of them here, just use `mvn
> > versions:display-plugin-updates` to pick them up ;)
> > (and more plugins to come).
> >
> > What I do want to share is about our upcoming Maven releases...
> >
> > Maven 3.9.7 is nearing (read: coming soon), and will have an important
> > Resolver update and other important fixes. Most importantly, the
> file-locks
> > are getting nice improvement (feedback VERY welcome).
> >
> > Maven 3.9.7 issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7
> >
> > Resolver 1.9.19 issues (mostly bug fixes):
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19
> >
> > At the same time, we plan to release Maven Daemon (m39) as well, to have
> it
> > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments
> > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
> > interchangeable on workstations.
> >
> > Next, Maven 4 is turning beta, so the next release will be beta1! And
> > again, same thing for Maven Damon (m40), we will have a release that will
> > include Maven 4 beta-1.
> >
> > Maven 4 beta-1
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1
> >
> > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1
> > release):
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11
> >
> > Keep your eyes on our upcoming releases,
> > and have fun!
> > - The Apache Maven team
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: Merge staged classifiers and deploy

2024-05-03 Thread Tamás Cservenák

Howdy,

We have a similar use case (unsolved yet, done manually) in maven-mvnd,
where native binaries for various OS es (produced by GraalVM) need to be
collected

Stay tuned.

T

On Thu, May 2, 2024 at 3:38 AM tison  wrote:

> Hi,
>
> I found the other thread talks about nexus-staging-plugin and it's
> deprecated.
>
> In Apache OpenDAL, we're currently relying on nexus-staging-plugin for
> merging staged classifiers (i.e., JARs with native library on different
> platforms) and deploy.
>
> We wrote [1] and [2] for doing so, and IIRC I spent a few days but fail to
> find the way achieve this in maven-deploy-plugin.
>
> [1]
>
> https://github.com/apache/opendal/blob/v0.45.1/.github/workflows/release_java.yml
> [2]
>
> https://github.com/apache/opendal/blob/v0.45.1/scripts/merge_local_staging.py
>
> Did you ever encounter this case? Is there any reference?
>
> Best,
> tison.
>

Re: maven-compat removal?

2024-04-30 Thread Tamás Cservenák

As Guillaume said, the time table of _actual removal_ from Maven (4) Core
is still questionable.
OTOH, we do want to _ensure_ that at least Maven Core Plugins are
maven-compat free...

Personal (biased) opinion: given how much of the plugin that claims itself
to be Maven3 plugin depends on maven-compat (explicitly or implicitly),
Maven 4.0 is most probably too early to remove it, DESPITE we talk about
maven-compat, a module that offers Maven2 compatibility layer. OTOH, the
_presence_ of this module is becoming an impediment for us, and we do want
to get rid of it, the sooner the better. On a related note: users who were
against Maven 3.9.x emitting warnings about deprecated plugins... They
"won", all the "Maven 3.9 should prepare for 4.0 work stopped", and this is
the price now: it is not simple to detect these plugins in the wild. I
understand "they (users) cannot do anything about warnings", but that could
be at least "they (users) live with warnings and report deprecation issues
to authors of deprecated plugins"... Currently we really have no clue how
many affected (non-core) Maven plugins could be out there, that would
simply break, if maven-compat would be removed.

Thanks
T

On Wed, May 1, 2024 at 12:32 AM Basil Crow  wrote:

> On Tue, Apr 30, 2024 at 2:42 PM Tamás Cservenák 
> wrote:
> >
> > This should have happened in last 10 years, but for some reason it
> didn't.
>
> Does the Maven project have a plan for ensuring that, once started,
> migrations are completed within a reasonable amount of time? In the
> Jenkins project, this is part of our engineering process at the design
> proposal stage:
>
>
> https://github.com/jenkinsci/jep/blob/eedd98dadbf70f69a291c9184facafc64dc82097/jep-template//README.adoc?plain=1#L150-L185
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: maven-compat removal?

2024-04-30 Thread Tamás Cservenák

This should have happened in last 10 years, but for some reason it didn't.
Basically, if plugin explicitly (or implicitly) depends on maven-compat, it
is still de facto a Maven2 plugin. In 2024. Go figure!

Thanks
T

On Tue, Apr 30, 2024, 23:30 Olivier Lamy  wrote:

> On Tue, 30 Apr 2024 at 15:56, Guillaume Nodet  wrote:
> >
> > Maven-compat has been deprecated years ago, so the goal would be to get
> rid
> > of it.
> > For months, efforts have been made to first make maven-compat completely
> > optional.
> > This is now the case in maven itself.
> > However, some plugins still rely on it and they should be migrated to use
> > Maven 3 apis.
> > This is a required step before being able to get rid of maven-compat.
> >
> > I'm still hesitant about the time table, whether maven-compat should be
> > removed from
> > 4.0 distribution or not.  It may be slightly premature, since a few
> plugins
> > still depend on it.
> >
>
> if we could have at least core plugins (default lifecycle) ready, that
> could work, but that's some work.
> but do you have some timeline in mind for 4.0? or it's just whenever
> it;s ready :)
>
>
>
> > Le mar. 30 avr. 2024 à 02:02, Olivier Lamy  a écrit :
> > >
> > > Hi,
> > > I can see plenty of PRs with maven-compat removal.
> > > Maybe this could be explained and so more people could help for this
> task?
> > >
> > > cheers
> > > Olivier
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[ANN] Maven Resolver 1.9.20 released

The Apache Maven team is pleased to announce the release of the
Maven Resolver 1.9.20:

The 1.x resolver lineage is in "bugfix only" maintenance mode.

===

https://maven.apache.org/resolver/

Release Notes - Maven Resolver - Version 1.9.20

** Bug
* [MRESOLVER-547] - BF collector always copies artifacts, even when it
should not
** Dependency upgrade
* [MRESOLVER-549] - Use parent POM 42
* [MRESOLVER-550] - Bump Redisson from 3.28.0 to 3.29.0
* [MRESOLVER-551] - (build) Bump japicmp from 0.17.2 to 0.21.1


Have fun,
-The Apache Maven team

[ANN] Apache Maven Resolver 2.0.0-alpha-11 released

The Apache Maven team is pleased to announce the release of the
Maven Resolver 2.0.0-alpha-11.

https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/

This is the last alpha release of Resolver 2.0.0, that would allow any
downstream consumers to try it out and adapt.

Release Notes - Maven Resolver - Version 2.0.0-alpha-11

** Bug
* [MRESOLVER-521] - File locking threads not entering critical region
were "oversleeping"
* [MRESOLVER-547] - BF collector always copies artifacts, even when it
should not
** New Feature
* [MRESOLVER-217] - Allow extra "sources" for Artifact decoration
* [MRESOLVER-518] - Improvements for version selector
** Improvement
* [MRESOLVER-519] - Drop copies of same method, re-add them to parent
(collectors)
* [MRESOLVER-520] - Move repeated code (decorators, generators) into
Utils
* [MRESOLVER-535] - DependencyGraphDumper should be configurable
* [MRESOLVER-536] - Skip setting last modified time when FS does not
support it
* [MRESOLVER-538] - In dirty tree, nodes coming from range (and parents
having ranges) should be detectable
* [MRESOLVER-540] - TransferResource can and should tell more about
transfer
* [MRESOLVER-542] - Reduce usage of final classes
** Task
* [MRESOLVER-552] - Redirect site creation to enable concurrent release
of 1.x and 2.x resolver
** Dependency upgrade
* [MRESOLVER-523] - Update GPG generator to Bouncycastle 1.78
* [MRESOLVER-524] - Update Hazelcast to 5.3.7
* [MRESOLVER-525] - Update test dep testcointainers-redis to 2.2.2
* [MRESOLVER-534] - Redisson 3.28.0
* [MRESOLVER-537] - Use slf4j 2.0.13
* [MRESOLVER-539] - Use parent POM 42
* [MRESOLVER-543] - (build) Bump
com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to 0.21.1
* [MRESOLVER-544] - Bump org.redisson:redisson from 3.28.0 to 3.29.0
* [MRESOLVER-545] - Bump bouncycastleVersion from 1.78 to 1.78.1
* [MRESOLVER-546] - Bump org.codehaus.plexus:plexus-utils from 4.0.0 to
4.0.1


Have fun,
-The Apache Maven team

[ANN] Apache Maven Deploy Plugin 3.1.2 Released

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

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

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


  org.apache.maven.plugins
  maven-deploy-plugin
  3.1.2


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

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

Release Notes - Maven Deploy Plugin - Version 3.1.2

** Improvement
* [MDEPLOY-313] - Upgrade maven-plugin parent to 41
* [MDEPLOY-314] - Include artifactId in messages of
DeployMojo#processProject
** Dependency upgrade
* [MDEPLOY-316] - Update parent to 42, up prerequisite to 3.6.3


Have fun,
-The Apache Maven team

[ANN] Apache Maven Install Plugin 3.1.2 Released

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

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

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


  org.apache.maven.plugins
  maven-install-plugin
  3.1.2


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

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

Release Notes - Maven Install Plugin - Version 3.1.2

** Bug
* [MINSTALL-190] - Fix Temporary File Information Disclosure
Vulnerability
** Improvement
* [MINSTALL-195] - Include artifactId in messages of
InstallMojo#processProject
** Task
* [MINSTALL-192] - Code cleanups
** Dependency upgrade
* [MINSTALL-193] - Upgrade Parent Version 42, require min Maven 3.6.3
* [MINSTALL-197] - Upgrade parent to 41, remove deprecations


Have fun,
-The Apache Maven team

[RESULT][VOTE] Release Maven Install Plugin 3.1.2

Howdy,

The vote has passed with the following result:

+1b: Sylwester, Herve, Arnaud, Olivier, Guillaume, Slawomir, Jermaine

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

[RESULT][VOTE] Release Maven Deploy Plugin 3.1.2

Howdy,

The vote has passed with the following result:

+1b: Sylwester, Herve, Arnaud, Olivier, Slawomir, Jermaine

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

[RESULT][VOTE] Release Maven Resolver 2.0.0-alpha-11

Howdy,

The vote has passed with the following result:

+1b: Herve, Slawomir, Jermaine, Tamas

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

[RESULT][VOTE] Release Maven Resolver 1.9.20

Howdy,

The vote has passed with the following result:

+1b: Herve, Arnaud, Slawomir, Olivier

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Maven Resolver 2.0.0-alpha-11

+1

On Fri, Apr 26, 2024 at 2:21 PM Tamás Cservenák  wrote:

> Howdy,
>
> Note: This is the last alpha release, next one will be beta-1. This
> version is to be picked up by Maven 4 beta-1. It contains 2 important bug
> fixes and other improvements.
>
> Note re site: as at this moment there are 2 simultaneously ongoing votes
> for Resolver 1.9.20 and 2.0.0-alpha-11 (that were done in this order), I
> changed staging site to LATEST-2.x. This is a temporary solution, in beta-1
> this will be undone (and if needed, Resolver 1.x will be changed to
> LATEST-1.x instead).
>
> For configuration changes, see
>
> https://maven.apache.org/resolver-archives/resolver-LATEST-2.x/configuration.html
>
> IF the vote is successful, the staging site will NOT be moved to
> https://maven.apache.org/resolver/ but instead will be made reachable
> from https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/
> only.
>
> The 1.9.19 (1.9.20 vote ongoing) is still the "latest stable" release of
> Maven Resolver.
>
> ===
>
> We solved 22 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12354454
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2102/
>
> Source release SHA512:
>
> cc0f6feb47ab7c292a1c63b2d42e77e9c1d33d956defbcf28251c33c9865307a7a34b844fd3f845bc97babd17d0ff5ce249728e1e1e0f665747d431ddd1f
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST-2.x/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

[VOTE] Release Maven Resolver 2.0.0-alpha-11

Howdy,

Note: This is the last alpha release, next one will be beta-1. This version
is to be picked up by Maven 4 beta-1. It contains 2 important bug fixes and
other improvements.

Note re site: as at this moment there are 2 simultaneously ongoing votes
for Resolver 1.9.20 and 2.0.0-alpha-11 (that were done in this order), I
changed staging site to LATEST-2.x. This is a temporary solution, in beta-1
this will be undone (and if needed, Resolver 1.x will be changed to
LATEST-1.x instead).

For configuration changes, see
https://maven.apache.org/resolver-archives/resolver-LATEST-2.x/configuration.html

IF the vote is successful, the staging site will NOT be moved to
https://maven.apache.org/resolver/ but instead will be made reachable from
https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/ only.

The 1.9.19 (1.9.20 vote ongoing) is still the "latest stable" release of
Maven Resolver.

===

We solved 22 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12354454

There are still some issues in JIRA:
https://issues.apache.org/jira/projects/MRESOLVER/issues

Staging repository:
https://repository.apache.org/content/repositories/maven-2102/

Source release SHA512:
cc0f6feb47ab7c292a1c63b2d42e77e9c1d33d956defbcf28251c33c9865307a7a34b844fd3f845bc97babd17d0ff5ce249728e1e1e0f665747d431ddd1f

Staging site:
https://maven.apache.org/resolver-archives/resolver-LATEST-2.x/

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

Vote open for 72 hours.

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

[VOTE] Release Maven Resolver 1.9.20

Howdy,

Note: Maven Resolver 1.x lineage is in "bugfix only" maintenance mode.

This Resolver 1.9.20 release is a bugfix release: A behaviour change
introduced by BF collector was fixed, that may affect 3rd party code.

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

There are still some issues in JIRA:
https://issues.apache.org/jira/projects/MRESOLVER/issues

Staging repository:
https://repository.apache.org/content/repositories/maven-2101/

Source release SHA512:
11b6d19927c3bf6ee486132ad1aed274fded1ac5bc996244efa9da7b831befeddec71775552fe5540fc6d1b3ca7dada68090cd38652d6592c29a9ab6e9a11b1b

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

[VOTE] Release Maven Deploy Plugin 3.1.2

Howdy,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317228=12354128

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MDEPLOY/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2100/

Source release checksum(s):
d45cc8431614d34b7d55c0a13e4a6387004add2dd3f5138b17d56be59e9787dcfe97f1e2250bc1549e4a9226dc9459673fd2dd9183f4926732253a344d231d79

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

[VOTE] Release Maven Install Plugin 3.1.2

Howdy,

We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317524=12353548

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MINSTALL/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2099/

Source release checksum(s):
f5847a66c2acc2b21b4afa5f4aa257ce3b41fcc63315720ccd68fa2cc497de8bef251ad500c6df051a2441846d521ce24de62858670f0c95101271166e9c6ce8

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

[ANN] Apache Maven Wrapper 3.3.1 Released

2024-04-25 Thread Tamás Cservenák

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

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

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

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

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

Release Notes - Maven Wrapper - Version 3.3.1

** Improvement
* [MWRAPPER-132] - Inlined mvnw Downloader.java uses `new URL(String)`,
which is deprecated in Java 21
* [MWRAPPER-134] - Provide a reliable way to determine the Maven
Wrapper version

Enjoy,
-The Apache Maven team

[RESULT][VOTE] Release Apache Maven Wrapper 3.3.1

2024-04-25 Thread Tamás Cservenák

Howdy,

The vote has passed with the following result:

+1b: Slawomir, Sylwester, Olivier, Tamas
+1nb: Matthias

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Apache Maven Wrapper 3.3.1

2024-04-25 Thread Tamás Cservenák

+1

On Tue, Apr 23, 2024 at 1:18 PM Olivier Lamy  wrote:

> +1
>
> On Tue, 23 Apr 2024 at 02:28, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > The importance of this release is to gain over 3.3.0: Two changes are in
> > this release, both are equally important, but MWRAPPER-134 adds simple
> > means for tooling to discover wrapper versions being used. With 3.3.0 we
> > lost this ability to figure out wrapper versions easily.
> >
> > We solved 2 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354586
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/projects/MWRAPPER/issues
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2097
> >
> > Source release checksum SHA512:
> >
> 270d843df1b5db108f5420c3ef9310ff1238d49b077c35cff6a5eca9f584f6f41ee9d82cba169fce2c6e768281cda9d84383ec75171640163d0966cc0f206949
> >
> > Staging site:
> > https://maven.apache.org/wrapper-archives/wrapper-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
>
>

Quo Vadis Maven?

2024-04-23 Thread Tamás Cservenák

Howdy,

This is just a short newsflash about upcoming planned releases related to
Maven.

Recently we got a huge spike in plugin releases, with various fixes and
improvements. I will not enumerate all of them here, just use `mvn
versions:display-plugin-updates` to pick them up ;)
(and more plugins to come).

What I do want to share is about our upcoming Maven releases...

Maven 3.9.7 is nearing (read: coming soon), and will have an important
Resolver update and other important fixes. Most importantly, the file-locks
are getting nice improvement (feedback VERY welcome).

Maven 3.9.7 issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7

Resolver 1.9.19 issues (mostly bug fixes):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19

At the same time, we plan to release Maven Daemon (m39) as well, to have it
aligned with Maven 3,9,7: with many bug fixes and improvements/alignments
to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
interchangeable on workstations.

Next, Maven 4 is turning beta, so the next release will be beta1! And
again, same thing for Maven Damon (m40), we will have a release that will
include Maven 4 beta-1.

Maven 4 beta-1
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1

Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1
release):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11

Keep your eyes on our upcoming releases,
and have fun!
- The Apache Maven team

Re: Replacement proposal for

2024-04-22 Thread Tamás Cservenák

+1

And I'd just add this to the discussion:
https://github.com/apache/maven-compiler-plugin/pull/160

:D

T

On Mon, Apr 22, 2024 at 2:54 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello all
>
> The Maven compiler plugin has an  boolean
> parameter with `true` as the default value. This parameter has issues
> discussed in MCOMPILER-209 [1], which has 61 votes. In short, builds are
> much faster when this parameter is set to `false`, which is
> counter-intuitive. During the refactoring for the Maven 4 compiler
> plugin, by looking at the source code, I saw the following issues with
> the current implementation:
>
>   * When  is enabled (which is the default),
> the plugin compares the list of source files in the current build
> with a list saved after the previous build in order to detect
> changes. But it seems to me that the plugin uses relative paths in
> one case, and absolute paths in the other cases. Consequently, the
> paths do not match and the plugin always thinks that all source
> files changed. I did not double-checked or tested (maybe I missed
> some `toAbsoluteFile()` calls). But if confirmed, it would explain
> the MCOMPILER-209 issue.
>   * The ways that the two lists are compared has a performance cost of
> O(N²). It could easily be O(N) instead by replacing one list by an
> hash set.
>   * The plugin tries to detect changes in dependencies, but the
> algorithm works only if the compilation never fail. Consider the
> following scenario:
>   o One project has 3 modules: A, B and C.
>   o Module B and C depends on A.
>   o Developer makes a change in A and run `mvn install`.
>   o Module A compiles successfully, but B fails because of the
> change in A.
>   o Developer fixes the build failure in B and run `mvn install`
> again. In this scenario, the incremental compilation will not
> see that C also needs to be rebuilt, because when
>  is enabled, the plugin compares the
> JAR timestamps with the build start time. In this scenario, the
> second build start time is after the `A.jar` creation time.
> Maybe this issue was unnoticed because the issue explained in
> the first bullet point caused the plugin to always recompile
> everything anyway.
>
> I propose to deprecate  in Maven 4 and
> replace it by a new parameter: . Its value would
> be a comma-separated list of values instead of a single boolean flag.
> Those values specify which methods to use for deciding which files to
> recompile:
>
>   * "sources": check for changes in source files, including whether a
> file has been deleted. This method uses a file saved by the previous
> build in the "target/maven-status"  directory (as done by the
> current implementation).
>   * "classes": check whether the source file is more recent than the
> class file. This method does not need any "maven-status" file from
> the previous build, but does not detect whether a file has been
> added or removed.
>   * "dependencies": check whether a dependency has changed (using a more
> robust algorithm than the current one).
>   * "modules": do not specify any file to the compiler and use the
> `--module` option instead, in which case the compiler will scan the
> directories itself and decides itself which files to recompile based
> on their timestamp. This option is available for modular projects only.
>
> The current  boolean flag maps to above
> proposal as below:
>
>   * `true` is approximately equivalent to "sources,dependencies", except
> that I propose to not rebuild everything when a file is added (it is
> usually not needed).
>   * `false` is equivalent to "classes".
>
> As seen from above, the current  actually
> mixes two aspects that could be treated separately: whether to check if
> a dependency changed, and whether to use a list saved from the previous
> build for checking if a source file changed. The comma-separated value
> proposal would allow users to control those aspects independently.
>
>  Martin
>
> [1]https://issues.apache.org/jira/browse/MCOMPILER-209
>

[VOTE] Release Apache Maven Wrapper 3.3.1

2024-04-22 Thread Tamás Cservenák

Howdy,

The importance of this release is to gain over 3.3.0: Two changes are in
this release, both are equally important, but MWRAPPER-134 adds simple
means for tooling to discover wrapper versions being used. With 3.3.0 we
lost this ability to figure out wrapper versions easily.

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354586

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MWRAPPER/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2097

Source release checksum SHA512:
270d843df1b5db108f5420c3ef9310ff1238d49b077c35cff6a5eca9f584f6f41ee9d82cba169fce2c6e768281cda9d84383ec75171640163d0966cc0f206949

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

[ANN] Apache Maven Wrapper 3.3.0 Released

2024-04-20 Thread Tamás Cservenák

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

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

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

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

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

Release Notes - Maven Wrapper - Version 3.3.0

** Bug
* [MWRAPPER-86] - Trim trailing slash in Repo URL
* [MWRAPPER-103] - Failed to validate Maven Wrapper SHA-256 on Windows
* [MWRAPPER-108] - mvnw script fails silently when download fails
* [MWRAPPER-112] - Detection of JAVA_HOME fails due to bad quoting
* [MWRAPPER-113] - Error and warning output goes to standard output and
intermingles with Maven output
* [MWRAPPER-120] - Maven wrapper plugin should not create wrapperUrl
property for script-only mode
* [MWRAPPER-123] - only-mvnw fails on ksh printf implementations
* [MWRAPPER-131] - Downloader downloads directly into target file
** Improvement
* [MWRAPPER-70] - Don't require a pom.xml
* [MWRAPPER-104] - Add prettier config for shell scripts
* [MWRAPPER-124] - MavenWrapperDownloader uses new URL(String), which
is deprecated in Java 21
* [MWRAPPER-125] - Make "only-script" the default wrapper
** Task
* [MWRAPPER-128] - Remove legacy
* [MWRAPPER-129] - Set plugin prerequisite to Maven 3.6.3
** Dependency upgrade
* [MWRAPPER-100] - Declare needed dependencies
* [MWRAPPER-115] - Bump org.codehaus.plexus:plexus-archiver from 4.6.2
to 4.9.1
* [MWRAPPER-118] - Bump org.codehaus.mojo:mrm-maven-plugin from 1.5.0
to 1.6.0
* [MWRAPPER-119] - Upgrade Parent to 41
* [MWRAPPER-126] - Upgrade org.codehaus.plexus:plexus-archiver to 4.9.2
* [MWRAPPER-127] - Bump commons-io:commons-io from 2.16.0 to 2.16.1
* [MWRAPPER-130] - Use Maven parent 42

Enjoy,
-The Apache Maven team

[RESULT][VOTE] Release Apache Maven Wrapper 3.3.0

2024-04-20 Thread Tamás Cservenák

Howdy,

The vote has passed with the following result:

+1b: Olivier, Karl-Heinz, Slawomir

PMC quorum: reached

I will promote the artifacts to the central repo, the source release
ZIP file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Apache Maven PMD Plugin version 3.22.0

2024-04-20 Thread Tamás Cservenák

+1

On Thu, Apr 18, 2024, 12:38 Andreas Dangel  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12353876=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2095/
>
> https://repository.apache.org/content/repositories/maven-2095/org/apache/maven/plugins/maven-pmd-plugin/3.22.0/maven-pmd-plugin-3.22.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.22.0-source-release.zip sha512:
>
> ebc08fa2b9b1c7ae3cb985d741ea2326e23752e5dabe764a213a7acca9c02287e4e15d6b274f9f8cabbc29193aaa622cbd9676a065a2cd5de7e4816eb918c0e8
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-pmd-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
>
>
> Regards,
> Andreas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Apache Maven Toolchains Plugin 3.2.0

+1

On Thu, Apr 18, 2024 at 2:52 AM Olivier Lamy  wrote:

> Hi,
> I'd like to release Apache Maven Toolchains Plugin 3.2.0
> We fixed 7 issues.
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2094/
>
> Source release checksum SHA512:
>
> c26ee136b19220cfdde41211426432feb8b042f23d96d9c490c0befa4986c89919ba412285a8acf621a2763ccfc5b768813df84669440bdef0a805ff623ef2ca
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-toolchains-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] Maven Resolver 1.9.19 released

The Apache Maven team is pleased to announce the release of the
Maven Resolver 1.9.19:

The 1.x resolver lineage is in "bugfix only" maintenance mode.

===

https://maven.apache.org/resolver/

Release Notes - Maven Resolver - Version 1.9.19

** Bug
* [MRESOLVER-483] - PreorderNodeListGenerator bug: may print trailing
":"
* [MRESOLVER-522] - File locking threads not entering critical region
were "oversleeping"
** Improvement
* [MRESOLVER-536] - Skip setting last modified time when FS does not
support it
** Dependency upgrade
* [MRESOLVER-527] - Hazelcast 5.3.7
* [MRESOLVER-528] - Redisson 3.28.0
* [MRESOLVER-529] - Commons Codec 1.16.1
* [MRESOLVER-530] - Eclipse Sisu 0.9.0.M2
* [MRESOLVER-531] - Maven 3.9.6 (demos)
* [MRESOLVER-532] - Guice 6.0.0 (and Guava 33.1.0)
* [MRESOLVER-533] - Jetty 9.4.54 (used in tests)

Have fun,
-The Apache Maven team

[ANN] Apache Maven GPG Plugin 3.2.4 Released

Howdy,

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

This release is a bugfix release.

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

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


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.2.4
** Bug
* [MGPG-125] - Due to default value of gpg.passphraseServerId,
bestPractices=true will always fail
** Dependency upgrade
* [MGPG-126] - Commons IO 2.16.1 (test dependency)

Have fun,
-The Apache Maven team

[RESULT] [VOTE] Release Maven Resolver 1.9.19

Howdy,

The vote has passed with the following result:

+1b: Olivier, Guillaume, Tamas

PMC quorum: reached

I will promote the artifacts to the central repo, the source release
ZIP file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Maven Resolver 1.9.19

+1

On Tue, Apr 16, 2024 at 3:19 PM Tamás Cservenák  wrote:

> Howdy,
>
> Note: Maven Resolver 1.x lineage is in "bugfix only" maintenance mode.
>
> This Resolver 1.9.19 release is a bugfix release: A file locking related
> bug was fixed, that explains a lot about mysterious "could not acquire
> lock" problems. A cosmetic bugfix, where generated classpath string may
> contain trailing colon (":"). And finally, an improvement, that makes
> resolver able to work on FS implementations that do not allow mtime
> updates, like some cloud FS implementations are.
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353946
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2090
>
> Source release SHA512:
>
> 1f8e0f457a0e27e61e9850f6c234d3fdca79764bf847a47cd40c09cb1bcdb8a2e1d6e21ff5789cb8bab416cb4b7c024afe84e68f19401f79f658ce7cc05cb8b4
>
> 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
>

[RESULT] [VOTE] Release Apache Maven GPG Plugin 3.2.4