from:"Tamás Cservenák"

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

[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

Re: [ANN] Apache Maven Wrapper 3.3.0 Released

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

Do you maybe use MAVEN_CONFIG?
See https://issues.apache.org/jira/browse/MWRAPPER-133

Thanks
T

On Thu, Apr 25, 2024 at 12:10 PM Sven Nguyen Van
 wrote:

> Hi,
>
> sadly, this update made several Jenkins-Pipelines fail here.
>
> RenovateBot tried to update the maven-wrapper in several of our projects,
> and during this update maven wrapper apparently switches to the new
> "only-script" default.
>
> Somehow this results in getting a
> > Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy)
> on project [..]: Failed to deploy artifacts: Could not transfer artifact
> [..](https://[..]): status code: 401, reason phrase: Unauthorized (401)
> -> [Help 1]
>
> Manually switching back to `-Dtype=bin` installs a different `mvnw`
> script, with which our `mvnw deploy` succeeds again. Of course, it would be
> better if the "only-script" mode would not disrupt maven-deploy, though i
> have no idea how this happens.
>
> Not just because of this, but also because of authentication and firewall
> hassles during dynamic downloads, it would be nice if i could configure
> (maybe in the maven-wrapper.properties) that it should keep using the
> bin-style.
>
>
> -- Sven Nguyen Van
>
> opta data Finance GmbH
> Berthold-Beitz-Boulevard 461, 45141 Essen, Tel.: +49 201 3196-0
> serv...@optadata-gruppe.de
> Geschäftsführer: Marcel Priester, Benedikt Steffen
> Amtsgericht Essen HRA B1995
> https://www.optadata-gruppe.de
>
> [opta data]
>
> Servicezeiten: Mo. - Fr. 07:00 bis 19:00 Uhr
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und vernichten Sie diese
> E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind
> nicht gestattet.
> [Logoleiste]
>

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: [ANN] Apache Maven Wrapper 3.3.0 Released

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

Agreed!

On Mon, Apr 22, 2024 at 12:27 PM Slawomir Jaranowski 
wrote:

> I would like to not add something which must be parsed in a magical way ...
> we can add a property that can be simply used.
>
> pon., 22 kwi 2024 o 12:06 Tamás Cservenák 
> napisał(a):
>
> > Good call...
> >
> > seems so... maybe we need to add some (clearly visible/parsable) value
> into
> > script, probably interpolated during build?
> >
> > T
> >
> > On Mon, Apr 22, 2024 at 11:46 AM Nils Breunese  wrote:
> >
> > > I use Renovate [0] to automatically keep dependencies up-to-date. I
> > > noticed that the upgrade to Maven Wrapper 3.3.0 removed the
> `wrapperUrl`
> > > line from `.mvn/wrapper/maven-wrapper.properties`. I guess that is
> > related
> > > to https://issues.apache.org/jira/browse/MWRAPPER-120.
> > >
> > > A couple of my colleagues implemented the support for keeping Maven
> > > Wrapper up-to-date in Renovate, and I believe Renovate currently
> > determines
> > > the version of Maven Wrapper based on the `wrapperUrl` property, so I
> > think
> > > that logic may need to be updated after this change. Is parsing the
> > `mvnw`
> > > / `./mvnw.bat` scripts themselves the only way to determine the Maven
> > > Wrapper version after this change?
> > >
> > > Nils.
> > >
> > > [0] https://github.com/renovatebot/renovate
> > >
> > > > Op 20 apr 2024, om 11:11 heeft Tamás Cservenák 
> > het
> > > volgende geschreven:
> > > >
> > > > 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
> > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [ANN] Apache Maven Wrapper 3.3.0 Released

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

Good call...

seems so... maybe we need to add some (clearly visible/parsable) value into
script, probably interpolated during build?

T

On Mon, Apr 22, 2024 at 11:46 AM Nils Breunese  wrote:

> I use Renovate [0] to automatically keep dependencies up-to-date. I
> noticed that the upgrade to Maven Wrapper 3.3.0 removed the `wrapperUrl`
> line from `.mvn/wrapper/maven-wrapper.properties`. I guess that is related
> to https://issues.apache.org/jira/browse/MWRAPPER-120.
>
> A couple of my colleagues implemented the support for keeping Maven
> Wrapper up-to-date in Renovate, and I believe Renovate currently determines
> the version of Maven Wrapper based on the `wrapperUrl` property, so I think
> that logic may need to be updated after this change. Is parsing the `mvnw`
> / `./mvnw.bat` scripts themselves the only way to determine the Maven
> Wrapper version after this change?
>
> Nils.
>
> [0] https://github.com/renovatebot/renovate
>
> > Op 20 apr 2024, om 11:11 heeft Tamás Cservenák  het
> volgende geschreven:
> >
> > 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
>
>

Re: Can properties be inherited like I expect them to be?

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

Howdy,

I did locally this
https://gist.github.com/cstamas/25f6c978d3eb0823fd0af8ef25c08d6f

And I think I got the behaviour that you expect.

Given a project can be built only with Java8+ this should be ok.

T

On Sun, Apr 21, 2024 at 4:03 PM Gary Gregory  wrote:

> Hi,
>
> A POM can't seem to inherit a parent POM configuration with properties
> redefined in a child POM profile.
>
> Am I doing something wrong?
>
> For example:
>
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> cd commons-bcel
> git checkout eba45c05365fc89b0007296fc3ee188cca5d091d
> maven
>
> This REQUIRES using Java 8, run the default goal: `mvn`
>
> and you'll get JaCoCo check failures because properties like
> commons.jacoco.classRatio are not (apparently) overridden in the Java
> 8 profile (id java-8) from 0.90 to 0.89.
>
> [INFO] Loading execution data file
> /Users/garydgregory/git/commons-bcel/target/jacoco.exec
> [INFO] Analyzed bundle 'bcel' with 408 classes
> [WARNING] Rule violated for bundle bcel: classes covered ratio is
> 0.89, but expected minimum is 1.00
> [WARNING] Rule violated for bundle bcel: instructions covered ratio is
> 0.65, but expected minimum is 0.90
> [WARNING] Rule violated for bundle bcel: methods covered ratio is
> 0.70, but expected minimum is 0.95
> [WARNING] Rule violated for bundle bcel: branches covered ratio is
> 0.59, but expected minimum is 0.85
> [WARNING] Rule violated for bundle bcel: lines covered ratio is 0.68,
> but expected minimum is 0.90
> [WARNING] Rule violated for bundle bcel: complexity covered ratio is
> 0.58, but expected minimum is 0.85
>
> Is there a way to get this to work?
>
> TY,
> Gary
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[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

[ANN] Maven Resolver 1.9.19 released

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

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

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

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

[ANN] Apache Maven GPG Plugin 3.2.3 Released

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

Howdy,

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

This release is a bugfix release, but also contains updated key
dependencies.

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


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

** Bug
* [MGPG-121] - Signing fails with 3.2.2:
"/Users/stevenobelia/.settings-security.xml (No such file or directory)"
** New Feature
* [MGPG-120] - Add new mojo: sign-deployed
** Improvement
* [MGPG-116] - Up the file size limit to 64K
* [MGPG-117] - Better handling of passphrase
** Dependency upgrade
* [MGPG-118] - Update to Commons IO 2.16.0
* [MGPG-122] - Update build dependency m-invoker-p to 3.6.1
* [MGPG-123] - Update to Bouncycastle 1.78
* [MGPG-124] - Update to junixsocket 2.9.1

Have fun,
-The Apache Maven team

Re: Maven & Github codespaces

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

Ok,

I _assumed this_ but hushed away when you said "works on my workstation".
Obviously NOT with 3.9.6, but some older Maven, as all Maven 3.9.x release
notes have this entry:
https://maven.apache.org/docs/3.9.6/release-notes.html#potentially-breaking-core-changes-if-migrating-from-3-8-x
(2nd bullet).

So if plugin is not fixed, you can fix it by adding explicitly dependency
onto plexus-utils in plugin dependencies entry

HTH
T

On Mon, Apr 1, 2024 at 1:39 PM Tommy Svensson  wrote:

> Hello Tamás,
>
> The problem is in mixin-maven-plugin which I found on GitHub and is 5
> years old! In this world that is a lot :-). It suddenly fails to find a
> "StringUtils" package that does not seem to exist in Maven Central. I
> suspect that StringUtils is something that should never have been submitted
> to maven-central, and have now been removed.
>
> So I'm looking for some other solution to re-use pom segments, in a future
> compatible way.
>
> /Tommy
>
> __
>
> Tommy Svensson
>
> to...@natusoft.se
>
>
>
>
> Från: Tamás Cservenák  
> Svara: Maven Users List  
> Datum: 1 april 2024 at 13:02:43
> Till: Maven Users List  
> Cc: Bernd Eckenfels  
> Ämne:  Re: Maven & Github codespaces
>
> Hi Tommy,
>
> would be good for reference (maybe someone else hits a similar issue) to
> have on ML the "solution" as well. At least some description of what
> exactly made you think "forgett maven on GitHub codespaces" and what you
> did to fix this.
>
> Thanks
> T
>
> On Mon, Apr 1, 2024 at 12:40 PM Tommy Svensson  wrote:
>
> > My brain screwed upp here! I incorrectly took this to be a maven issue!
> I
> > have just figured out that Maven has nothing to do with this problem!
> > Sorry!
> >
> > When I came to that conclusion things made much more sense :-).
> > __
> > Tommy Svensson
> > to...@natusoft.se
> >
> >
> >
> > Från: Bernd Eckenfels 
> > Svara: Maven Users List 
> > Datum: 31 mars 2024 at 23:59:20
> > Till: users@maven.apache.org 
> > Ämne: Re: Maven & Github codespaces
> >
> > Tommy Svensson wrote on 31. Mar 2024 14:52 (GMT +02:00):
> >
> > > …I have old jars somewhere! I should clean my
> > > ~/.m2/repository!
> >
> > It should work regardless what you have on your local reponczche since
> > it’s versioned. But other question how is that related to what’s in a
> fresh
> > codespace? Something goes not check out. Or are you saying it does never
> > work?
> >
> > Gruß
> > Bernd
> > —
> > https://bernd.eckenfels.net
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven & Github codespaces

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

Hi Tommy,

would be good for reference (maybe someone else hits a similar issue) to
have on ML the "solution" as well. At least some description of what
exactly made you think "forgett maven on GitHub codespaces" and what you
did to fix this.

Thanks
T

On Mon, Apr 1, 2024 at 12:40 PM Tommy Svensson  wrote:

> My brain screwed upp here! I incorrectly took this to be a maven issue! I
> have just figured out that Maven has nothing to do with this problem!
> Sorry!
>
> When I came to that conclusion things made much more sense :-).
> __
> Tommy Svensson
> to...@natusoft.se
>
>
>
> Från: Bernd Eckenfels 
> Svara: Maven Users List 
> Datum: 31 mars 2024 at 23:59:20
> Till: users@maven.apache.org 
> Ämne:  Re: Maven & Github codespaces
>
> Tommy Svensson wrote on 31. Mar 2024 14:52 (GMT +02:00):
>
> > …I have old jars somewhere! I should clean my
> > ~/.m2/repository!
>
> It should work regardless what you have on your local reponczche since
> it’s versioned. But other question how is that related to what’s in a fresh
> codespace? Something goes not check out. Or are you saying it does never
> work?
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Re: [DISCUSS] Maven Dependency Plugin

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

Howdy,

0.1.3 out, got unpack ability (actually UnpackSink). Here is 0.1.3 in
action, doing "side-by-side" and "overlay" way of unpack:
https://gist.github.com/cstamas/36c49da724100a19feab1397e7381d0f

Oh, and Martin, the sink also unpacks only "unique" artifacts, so it will
not over-and-over-and-over unpack the same thing...

T

On Tue, Mar 26, 2024 at 9:07 PM Tamás Cservenák  wrote:

> Oh, and as a side effect, the plugin is way more snappier as well, look at
> execution time diffs (I know, this is not "benchmark", but is telling):
> https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51
>
> toolbox needs almost only 60% of runtime that m-dep-p have.
>
> T
>
> On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák 
> wrote:
>
>> Rudimentary support for those is already present (equals, startWith,
>> endsWith) :)
>>
>> So one can write ArtifactMatcher "spec expression" (that will be parsed
>> into ArtifactMatcher that is actually Predicate) as:
>> "artifact(gavoid)"
>> where "gavoid" can be "string" or "g:a" or "g:a:v" etc
>> Each field currently support:
>> * - any
>> foo - equals foo
>> foo* - "starts with foo"
>> *foo - "ends with foo"
>>
>> Here is UT
>>
>> https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java
>>
>> So for your case, to filter dependencies by classifier it would be
>>
>> "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance
>> that filters for "classifier ends with x86".
>> "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance
>> that filters for "classifier starts with native".
>> etc
>>
>> key to interpret is here:
>>
>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250
>> and that prototype is later used here
>>
>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84
>>
>> T
>>
>>
>>
>>
>>
>> On Tue, Mar 26, 2024 at 8:41 PM Francois Marot 
>> wrote:
>>
>>> Thanks Tamas for all your work. I'll sure have a look (but not right now
>>> as
>>> I'm in a train station on a phone). Just to mention a feature I missed
>>> yesterday in m-d-p: ability to filter on classifiers including
>>> *wildcards*.
>>> Because I have dependencies with this kind of classifiers: natives-win,
>>> natives-linux,  natives-x86, natives-amd64 and so on...
>>>
>>> Wildcard are sometimes a feature I miss in many plugins.
>>> Thanks again for the work, wildcards or not !
>>>
>>> Francois
>>>
>>> Le mar. 26 mars 2024, 17:58, Tamás Cservenák  a
>>> écrit :
>>>
>>> > Just for those brave... if you toy with it.
>>> >
>>> > The "copy" and "copy-transitive" CLI commands and Mojos have
>>> "targetSpec"
>>> > parameters, that are parsed into ArtifactSink here:
>>> >
>>> >
>>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288
>>> >
>>> > So, the copy (and copy-transitive) resolve (transitively) and push the
>>> > results into an ArtifactSink.
>>> >
>>> > Sink spec can be:
>>> > "foo" -> implied "flat:foo"
>>> > "flat:" -> a "flat directory" to copy artifacts to, like
>>> "flat:lib"
>>> > (is resolved from basedir)
>>> > "repository:" -> creates a repo that can be used as "file://"
>>> uri or
>>> > published via HTTP (is resolved from basedir)
>>> > "install:" -> will install them into local repository (session
>>> > default in no path specified), ie. good to prep a local repo -- TBD
>>> 
>>> > param
>>> > "deploy:id::url" -> will deploy them to Remote Repo
>>> > "purge:" -> will purge them from local repository (session
>>> default in
>>> > no path specified) -- TBD  param
>>> >
>>> > So, following command:
>>> >
>>> > copy -DdepSpe

Re: Maven & Github codespaces

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

Yes, it works! I just said a few emails ago that I am using Maven 3.9.6 on
Java 21 since that Java was out.

T

On Thu, Mar 28, 2024 at 12:47 PM Tommy Svensson  wrote:

> I can add that on my computer I can do "mvn wrapper:wrapper" to install
> mvnw, and then build using that problems, but on github codespaces the
> wrapper instalation fails due to the same "StringUtils" failure!
>
> Do maven support the higher number versions of the JDK ?
>
> __
> Tommy Svensson
> to...@natusoft.se (mailto:to...@natusoft.se)
>
> På 27 mars 2024 till 18:05:18, Mantas Gridinas (mgridi...@gmail.com
> (mailto:mgridi...@gmail.com)) skrev:
>
> > Are you sure jdk21 is default on codespaces? An hour ago i cloned a java
> > repository only to find that codespaces comes with 11 by default. Whats
> > your output of java -version?
> >
> > Regardless, you can download your needed jdk from adoptium, and setup
> both
> > $PATH and $JAVA_HOME to point to the downloaded jdk just as you would on
> > normal machine.
> >
> >
> > On Wed, Mar 27, 2024, 19:01 Tommy Svensson  wrote:
> >
> > > Hello Maven users!
> > >
> > > I am having problem building with maven on a GitHub codespace!
> > >
> > > It complains about; Caused by: java.lang.ClassNotFoundException:
> > > org.codehaus.plexus.util.StringUtils
> > >
> > > I believe this is due to only JD17 and JDK21 is available with JDK21
> being
> > > the default.
> > >
> > > My problem is that locally on my private machine it builds fine, but on
> > > GitHub spaces I get:
> > >
> > > Caused by: java.lang.ClassNotFoundException:
> > > org.codehaus.plexus.util.StringUtils
> > > at
> > >
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > > at
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> > > at
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> > > at
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> > >
> > > The maven version is:
> > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > >
> > > Is there any known solution for this combination / situation or is it
> just
> > > "forgett maven on GitHub codespaces" ?
> > >
> > > Best Regards,
> > > Tommy Svensson
> > > __
> > > Tommy Svensson
> > > to...@natusoft.se (mailto:to...@natusoft.se)
> > >
> > >
>

Re: Maven & Github codespaces

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

Howdy,

Am using 3.9.6 on 21 on a regular basis, and Maven per se does nor have
this issue.
How did you install Maven 3.9.6? Did you verify that the download is not
damaged for example?

T

On Wed, Mar 27, 2024 at 6:00 PM Tommy Svensson  wrote:

> Hello Maven users!
>
> I am having problem building with maven on a GitHub codespace!
>
> It complains about; Caused by: java.lang.ClassNotFoundException:
> org.codehaus.plexus.util.StringUtils
>
> I believe this is due to only JD17 and JDK21 is available with JDK21 being
> the default.
>
> My problem is that locally on my private machine it builds fine, but on
> GitHub spaces I get:
>
> Caused by: java.lang.ClassNotFoundException:
> org.codehaus.plexus.util.StringUtils
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>
> The maven version is:
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
>
> Is there any known solution for this combination / situation or is it just
> "forgett maven on GitHub codespaces" ?
>
> Best Regards,
> Tommy Svensson
> __
> Tommy Svensson
> to...@natusoft.se (mailto:to...@natusoft.se)
>
>

Re: [DISCUSS] Maven Dependency Plugin

Oh, and as a side effect, the plugin is way more snappier as well, look at
execution time diffs (I know, this is not "benchmark", but is telling):
https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51

toolbox needs almost only 60% of runtime that m-dep-p have.

T

On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák  wrote:

> Rudimentary support for those is already present (equals, startWith,
> endsWith) :)
>
> So one can write ArtifactMatcher "spec expression" (that will be parsed
> into ArtifactMatcher that is actually Predicate) as:
> "artifact(gavoid)"
> where "gavoid" can be "string" or "g:a" or "g:a:v" etc
> Each field currently support:
> * - any
> foo - equals foo
> foo* - "starts with foo"
> *foo - "ends with foo"
>
> Here is UT
>
> https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java
>
> So for your case, to filter dependencies by classifier it would be
>
> "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance
> that filters for "classifier ends with x86".
> "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance
> that filters for "classifier starts with native".
> etc
>
> key to interpret is here:
>
> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250
> and that prototype is later used here
>
> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84
>
> T
>
>
>
>
>
> On Tue, Mar 26, 2024 at 8:41 PM Francois Marot 
> wrote:
>
>> Thanks Tamas for all your work. I'll sure have a look (but not right now
>> as
>> I'm in a train station on a phone). Just to mention a feature I missed
>> yesterday in m-d-p: ability to filter on classifiers including
>> *wildcards*.
>> Because I have dependencies with this kind of classifiers: natives-win,
>> natives-linux,  natives-x86, natives-amd64 and so on...
>>
>> Wildcard are sometimes a feature I miss in many plugins.
>> Thanks again for the work, wildcards or not !
>>
>> Francois
>>
>> Le mar. 26 mars 2024, 17:58, Tamás Cservenák  a
>> écrit :
>>
>> > Just for those brave... if you toy with it.
>> >
>> > The "copy" and "copy-transitive" CLI commands and Mojos have
>> "targetSpec"
>> > parameters, that are parsed into ArtifactSink here:
>> >
>> >
>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288
>> >
>> > So, the copy (and copy-transitive) resolve (transitively) and push the
>> > results into an ArtifactSink.
>> >
>> > Sink spec can be:
>> > "foo" -> implied "flat:foo"
>> > "flat:" -> a "flat directory" to copy artifacts to, like
>> "flat:lib"
>> > (is resolved from basedir)
>> > "repository:" -> creates a repo that can be used as "file://" uri
>> or
>> > published via HTTP (is resolved from basedir)
>> > "install:" -> will install them into local repository (session
>> > default in no path specified), ie. good to prep a local repo -- TBD
>> 
>> > param
>> > "deploy:id::url" -> will deploy them to Remote Repo
>> > "purge:" -> will purge them from local repository (session
>> default in
>> > no path specified) -- TBD  param
>> >
>> > So, following command:
>> >
>> > copy -DdepSpec="any()" -DtargetSpec="purge:"
>> >
>> > actually does the purge from the local repository. Same stands for
>> gav-copy
>> > (and gav-copy-transitively), but they do not use MavenProject to
>> > "contextualize" but need to be told explicitly what to resolve...
>> >
>> >
>> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák 
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > Yes, m-dep-p is under maintained, it actually would need a rewrite as
>> it
>> > > still uses MAT (and many other Maven2 archaic stuff) internally.
>> > > Hence, it will fail if used with 3.9+ features like "split repository"
>> > and
>> > >

Re: [DISCUSS] Maven Dependency Plugin

Rudimentary support for those is already present (equals, startWith,
endsWith) :)

So one can write ArtifactMatcher "spec expression" (that will be parsed
into ArtifactMatcher that is actually Predicate) as:
"artifact(gavoid)"
where "gavoid" can be "string" or "g:a" or "g:a:v" etc
Each field currently support:
* - any
foo - equals foo
foo* - "starts with foo"
*foo - "ends with foo"

Here is UT
https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java

So for your case, to filter dependencies by classifier it would be

"artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance that
filters for "classifier ends with x86".
"artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance
that filters for "classifier starts with native".
etc

key to interpret is here:
https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250
and that prototype is later used here
https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84

T





On Tue, Mar 26, 2024 at 8:41 PM Francois Marot 
wrote:

> Thanks Tamas for all your work. I'll sure have a look (but not right now as
> I'm in a train station on a phone). Just to mention a feature I missed
> yesterday in m-d-p: ability to filter on classifiers including *wildcards*.
> Because I have dependencies with this kind of classifiers: natives-win,
> natives-linux,  natives-x86, natives-amd64 and so on...
>
> Wildcard are sometimes a feature I miss in many plugins.
> Thanks again for the work, wildcards or not !
>
> Francois
>
> Le mar. 26 mars 2024, 17:58, Tamás Cservenák  a
> écrit :
>
> > Just for those brave... if you toy with it.
> >
> > The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec"
> > parameters, that are parsed into ArtifactSink here:
> >
> >
> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288
> >
> > So, the copy (and copy-transitive) resolve (transitively) and push the
> > results into an ArtifactSink.
> >
> > Sink spec can be:
> > "foo" -> implied "flat:foo"
> > "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib"
> > (is resolved from basedir)
> > "repository:" -> creates a repo that can be used as "file://" uri
> or
> > published via HTTP (is resolved from basedir)
> > "install:" -> will install them into local repository (session
> > default in no path specified), ie. good to prep a local repo -- TBD
> 
> > param
> > "deploy:id::url" -> will deploy them to Remote Repo
> > "purge:" -> will purge them from local repository (session default
> in
> > no path specified) -- TBD  param
> >
> > So, following command:
> >
> > copy -DdepSpec="any()" -DtargetSpec="purge:"
> >
> > actually does the purge from the local repository. Same stands for
> gav-copy
> > (and gav-copy-transitively), but they do not use MavenProject to
> > "contextualize" but need to be told explicitly what to resolve...
> >
> >
> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > Yes, m-dep-p is under maintained, it actually would need a rewrite as
> it
> > > still uses MAT (and many other Maven2 archaic stuff) internally.
> > > Hence, it will fail if used with 3.9+ features like "split repository"
> > and
> > > is suboptimal in many areas.
> > >
> > > Toolbox 0.1.0 released, btw:
> > >
> > > jbang toolbox@maveniverse
> > >
> > > or
> > >
> > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl
> > >
> > > to enter REPL (same as in MIMA CLI was).
> > >
> > > T
> > >
> > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala 
> > > wrote:
> > >
> > >> Hello Tamás,
> > >>
> > >> For context, what are the tensions that you're trying to solve here?
> > >>
> > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen
> > sink?
> > >>
> > >> Do some goals feel like a bad fit?
>

Re: [DISCUSS] Maven Dependency Plugin

Just for those brave... if you toy with it.

The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec"
parameters, that are parsed into ArtifactSink here:
https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288

So, the copy (and copy-transitive) resolve (transitively) and push the
results into an ArtifactSink.

Sink spec can be:
"foo" -> implied "flat:foo"
"flat:" -> a "flat directory" to copy artifacts to, like "flat:lib"
(is resolved from basedir)
"repository:" -> creates a repo that can be used as "file://" uri or
published via HTTP (is resolved from basedir)
"install:" -> will install them into local repository (session
default in no path specified), ie. good to prep a local repo -- TBD 
param
"deploy:id::url" -> will deploy them to Remote Repo
"purge:" -> will purge them from local repository (session default in
no path specified) -- TBD  param

So, following command:

copy -DdepSpec="any()" -DtargetSpec="purge:"

actually does the purge from the local repository. Same stands for gav-copy
(and gav-copy-transitively), but they do not use MavenProject to
"contextualize" but need to be told explicitly what to resolve...


On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák  wrote:

> Howdy,
>
> Yes, m-dep-p is under maintained, it actually would need a rewrite as it
> still uses MAT (and many other Maven2 archaic stuff) internally.
> Hence, it will fail if used with 3.9+ features like "split repository" and
> is suboptimal in many areas.
>
> Toolbox 0.1.0 released, btw:
>
> jbang toolbox@maveniverse
>
> or
>
> mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl
>
> to enter REPL (same as in MIMA CLI was).
>
> T
>
> On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala 
> wrote:
>
>> Hello Tamás,
>>
>> For context, what are the tensions that you're trying to solve here?
>>
>> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink?
>>
>> Do some goals feel like a bad fit?
>>
>> Are you thinking of breaking it up or replacing it?
>>
>> Greg
>>
>> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák 
>> wrote:
>>
>> > Howdy,
>> >
>> > just to not let this discussion die off. Let me show a take on a "how
>> > modern Maven plugin should look like" (that targets m-dependency-p
>> goals,
>> > sans analyze and some others) could look like:
>> > https://github.com/maveniverse/toolbox
>> >
>> > The "unpack" related goals are missing, not yet done, but there are
>> already
>> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same
>> as
>> > CLI commands, and they do NOT require Project, are meant to be "ad hoc"
>> > invoked.
>> > The non-"gav-"-prefixed mojos use MavenProject instead to
>> "contextualize"
>> > themselves (so they work with the Project, and the "plugin-" prefixed
>> ones
>> > with Project defined plugins).
>> >
>> > Note1: not yet released (is not on Central), if you want to test drive
>> it,
>> > build it locally).
>> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI
>> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar)
>> > Note3: some of the missing goals mentioned on this thread are
>> implemented
>> >
>> > Thanks
>> > T
>> >
>>
>

Re: [DISCUSS] Maven Dependency Plugin

Howdy,

Yes, m-dep-p is under maintained, it actually would need a rewrite as it
still uses MAT (and many other Maven2 archaic stuff) internally.
Hence, it will fail if used with 3.9+ features like "split repository" and
is suboptimal in many areas.

Toolbox 0.1.0 released, btw:

jbang toolbox@maveniverse

or

mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl

to enter REPL (same as in MIMA CLI was).

T

On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala  wrote:

> Hello Tamás,
>
> For context, what are the tensions that you're trying to solve here?
>
> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink?
>
> Do some goals feel like a bad fit?
>
> Are you thinking of breaking it up or replacing it?
>
> Greg
>
> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > just to not let this discussion die off. Let me show a take on a "how
> > modern Maven plugin should look like" (that targets m-dependency-p goals,
> > sans analyze and some others) could look like:
> > https://github.com/maveniverse/toolbox
> >
> > The "unpack" related goals are missing, not yet done, but there are
> already
> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same
> as
> > CLI commands, and they do NOT require Project, are meant to be "ad hoc"
> > invoked.
> > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize"
> > themselves (so they work with the Project, and the "plugin-" prefixed
> ones
> > with Project defined plugins).
> >
> > Note1: not yet released (is not on Central), if you want to test drive
> it,
> > build it locally).
> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI
> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar)
> > Note3: some of the missing goals mentioned on this thread are implemented
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Maven Dependency Plugin

Howdy,

just to not let this discussion die off. Let me show a take on a "how
modern Maven plugin should look like" (that targets m-dependency-p goals,
sans analyze and some others) could look like:
https://github.com/maveniverse/toolbox

The "unpack" related goals are missing, not yet done, but there are already
33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as
CLI commands, and they do NOT require Project, are meant to be "ad hoc"
invoked.
The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize"
themselves (so they work with the Project, and the "plugin-" prefixed ones
with Project defined plugins).

Note1: not yet released (is not on Central), if you want to test drive it,
build it locally).
Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI
uber is toolbox-1.0.0-SNAPSHOT-cli.jar)
Note3: some of the missing goals mentioned on this thread are implemented

Thanks
T

On Sat, Mar 23, 2024 at 9:43 AM Oliver B. Fischer 
wrote:

> Yes, all of them.
>
> purge-local-repository I use very often in Jenkins pipelines to clean up
> afterwards.
>
> Over the years I build a lot of pipelines, added checks to projects and so
> on. The dependency plugin was very often my rescue. I can't remember each
> single usage and project and its context, but there is a reason why these
> goals/functions have been added.
>
> Oliver
>
>
>
>
> Am 21.03.24 um 19:43 schrieb Tamás Cservenák:
> > Howdy,
> >
> > Oliver: all, really?
> > I wonder what you used for goals like "purge-local-repository",
> > "resolve-plugins" etc  :)
> >
> > I mean, I know what those goals do, I am just unsure WHY you needed
> those.
> >
> > T
> >
> > On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer<
> o.b.fisc...@swe-blog.net>
> > wrote:
> >
> >> Hi,
> >>
> >> over the time I used all of them in different projects and I think all
> >> of them are needed.
> >>
> >> Viele Grüße
> >>
> >> Oliver
> >>
> >>
> >> Am 21.03.24 um 17:04 schrieb Tamás Cservenák:
> >>> Howdy,
> >>>
> >>> I'd would be interested in how users and devs are using
> >>> maven-dependency-plugin:
> >>> https://maven.apache.org/plugins/maven-dependency-plugin/
> >>>
> >>> I collected some basic questions I'd like to have answered (but feel
> free
> >>> to add more info!):
> >>> - which goals are "must have" for you
> >>> - which goals are "I never touched" for you (or, "I really don't need"
> or
> >>> "never used" or "shrug")
> >>> - what is missing?
> >>>
> >>> Thanks
> >>> T
> >>>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> eo.b.fisc...@swe-blog.net
> >>
> >>
> >> -
> >> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail:users-h...@maven.apache.org
> >>
> >>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> eo.b.fisc...@swe-blog.net
>

[ANN] Apache Maven GPG Plugin 3.2.2 Released

Howdy,

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

This release is a bugfix, restoring the sign-and-deploy Mojo to pick up
remote repository authentication from settings.xml. Also contains smaller
improvements as well.

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


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

** Bug
* [MGPG-113] - Upgrading from 3.1.0 to 3.2.1 with no other changes
causes "gpg:sign-and-deploy-file" failed: 401 Unauthorized
** Improvement
* [MGPG-114] - BC Allow key size greater than 5KB from file
* [MGPG-115] - Show more information about key used to sign

Have fun,
-The Apache Maven team

Re: [DISCUSS] Maven Dependency Plugin

Greg,

For example, we recently converted the TrinoDB (
https://github.com/trinodb/trino) build, removed their use of "go offline"
So am just interested in any other patterns out there.

T

On Thu, Mar 21, 2024 at 9:40 PM Greg Chabala  wrote:

> I do have an example at hand, though I am not sure I would advocate for it:
> https://blog.frankel.ch/faster-maven-builds/2/
>
> There are undoubtedly better ways to achieve the author's goals, but I'm
> not sure that's the fault of dependency:go-offline.
>
> On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák 
> wrote:
>
> > Greg,
> >
> > would like to see such a project, do you have any examples at hand?
> > Am sure there are much simpler/better/more correct ways to do the same
> > thing.
> >
> > T
> >
> > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala 
> > wrote:
> >
> > > My understanding is dependency:go-offline is an effective way to
> > > pre-download plugins and dependencies, for instance if one is making
> some
> > > layer in a docker build container for later reuse.
> > >
> > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > What is the use case of "go offline"?
> > > > That is yet another goal coming from "Maven2 era" and messes up your
> > > local
> > > > repository (wrt back tracing dependencies,
> > > > https://issues.apache.org/jira/browse/MNG-7619)
> > > > I mean, if you do a build (w/o tests, or skipping most time stealing
> > > > steps), like "dry build", why is that not an option?
> > > >
> > > > T
> > > >
> > > >
> > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz 
> > wrote:
> > > >
> > > > > +1 to this list from Slawomir:
> > > > >
> > > > > - dependency:analyze /  dependency:analyze-only
> > > > > - dependency:copy
> > > > > - dependency:copy-dependencies
> > > > > - dependency:go-offline
> > > > > - dependency:list
> > > > > - dependency:tree
> > > > > - dependency:unpack
> > > > > - dependency:unpack-dependencies
> > > > >
> > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski <
> > > > > s.jaranow...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi
> > > > > > I use:
> > > > > >
> > > > > > - dependency:analyze /  dependency:analyze-only
> > > > > > - dependency:copy
> > > > > > - dependency:copy-dependencies
> > > > > > - dependency:go-offline
> > > > > > - dependency:list
> > > > > > - dependency:tree
> > > > > > - dependency:unpack
> > > > > > - dependency:unpack-dependencies
> > > > > >
> > > > > >
> > > > > >
> > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák 
> > > > > > napisał(a):
> > > > > >
> > > > > > > Howdy,
> > > > > > >
> > > > > > > I'd would be interested in how users and devs are using
> > > > > > > maven-dependency-plugin:
> > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/
> > > > > > >
> > > > > > > I collected some basic questions I'd like to have answered (but
> > > feel
> > > > > free
> > > > > > > to add more info!):
> > > > > > > - which goals are "must have" for you
> > > > > > > - which goals are "I never touched" for you (or, "I really
> don't
> > > > need"
> > > > > or
> > > > > > > "never used" or "shrug")
> > > > > > > - what is missing?
> > > > > > >
> > > > > > > Thanks
> > > > > > > T
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven Dependency Plugin

Greg,

would like to see such a project, do you have any examples at hand?
Am sure there are much simpler/better/more correct ways to do the same
thing.

T

On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala  wrote:

> My understanding is dependency:go-offline is an effective way to
> pre-download plugins and dependencies, for instance if one is making some
> layer in a docker build container for later reuse.
>
> On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > What is the use case of "go offline"?
> > That is yet another goal coming from "Maven2 era" and messes up your
> local
> > repository (wrt back tracing dependencies,
> > https://issues.apache.org/jira/browse/MNG-7619)
> > I mean, if you do a build (w/o tests, or skipping most time stealing
> > steps), like "dry build", why is that not an option?
> >
> > T
> >
> >
> > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz  wrote:
> >
> > > +1 to this list from Slawomir:
> > >
> > > - dependency:analyze /  dependency:analyze-only
> > > - dependency:copy
> > > - dependency:copy-dependencies
> > > - dependency:go-offline
> > > - dependency:list
> > > - dependency:tree
> > > - dependency:unpack
> > > - dependency:unpack-dependencies
> > >
> > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski <
> > > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > > I use:
> > > >
> > > > - dependency:analyze /  dependency:analyze-only
> > > > - dependency:copy
> > > > - dependency:copy-dependencies
> > > > - dependency:go-offline
> > > > - dependency:list
> > > > - dependency:tree
> > > > - dependency:unpack
> > > > - dependency:unpack-dependencies
> > > >
> > > >
> > > >
> > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák 
> > > > napisał(a):
> > > >
> > > > > Howdy,
> > > > >
> > > > > I'd would be interested in how users and devs are using
> > > > > maven-dependency-plugin:
> > > > > https://maven.apache.org/plugins/maven-dependency-plugin/
> > > > >
> > > > > I collected some basic questions I'd like to have answered (but
> feel
> > > free
> > > > > to add more info!):
> > > > > - which goals are "must have" for you
> > > > > - which goals are "I never touched" for you (or, "I really don't
> > need"
> > > or
> > > > > "never used" or "shrug")
> > > > > - what is missing?
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
>

Re: [DISCUSS] Maven Dependency Plugin

So,

in Maven2, the local repo was really "just a bunch of files" (totally wild
west).

With Maven3, and Resolver (yes, this is true from 3.0) the "enhanced" local
repository is used, that tries to "track" origin (of cached, not installed)
artifacts.
In Maven 3.9 the next step is made, which is a "split local repository",
where files (as opposed to "enhanced") are physically kept in split
locations.

All goals and plugins that _assume_ that local repository is "just a bunch
of files" are wrong, and should be avoided.
(this was the reason for all the plugin warnings in Maven 3.9.x line as
well, to make them stand out, and have plugin authors make the step of
correcting them, or users abandoning them)

A related typical example was
https://issues.apache.org/jira/browse/MASSEMBLY-957 where it was "assumed"
that "local" and "remote" repository notion is interchangeable. Is not.
These (mis)conceptions must go away.

T

On Thu, Mar 21, 2024 at 8:54 PM Tamás Cservenák  wrote:

> Howdy,
>
> What is the use case of "go offline"?
> That is yet another goal coming from "Maven2 era" and messes up your local
> repository (wrt back tracing dependencies,
> https://issues.apache.org/jira/browse/MNG-7619)
> I mean, if you do a build (w/o tests, or skipping most time stealing
> steps), like "dry build", why is that not an option?
>
> T
>
>
> On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz  wrote:
>
>> +1 to this list from Slawomir:
>>
>> - dependency:analyze /  dependency:analyze-only
>> - dependency:copy
>> - dependency:copy-dependencies
>> - dependency:go-offline
>> - dependency:list
>> - dependency:tree
>> - dependency:unpack
>> - dependency:unpack-dependencies
>>
>> On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski <
>> s.jaranow...@gmail.com>
>> wrote:
>>
>> > Hi
>> > I use:
>> >
>> > - dependency:analyze /  dependency:analyze-only
>> > - dependency:copy
>> > - dependency:copy-dependencies
>> > - dependency:go-offline
>> > - dependency:list
>> > - dependency:tree
>> > - dependency:unpack
>> > - dependency:unpack-dependencies
>> >
>> >
>> >
>> > czw., 21 mar 2024 o 17:06 Tamás Cservenák 
>> > napisał(a):
>> >
>> > > Howdy,
>> > >
>> > > I'd would be interested in how users and devs are using
>> > > maven-dependency-plugin:
>> > > https://maven.apache.org/plugins/maven-dependency-plugin/
>> > >
>> > > I collected some basic questions I'd like to have answered (but feel
>> free
>> > > to add more info!):
>> > > - which goals are "must have" for you
>> > > - which goals are "I never touched" for you (or, "I really don't
>> need" or
>> > > "never used" or "shrug")
>> > > - what is missing?
>> > >
>> > > Thanks
>> > > T
>> > >
>> >
>> >
>> > --
>> > Sławomir Jaranowski
>> >
>>
>

Re: [DISCUSS] Maven Dependency Plugin

Howdy,

What is the use case of "go offline"?
That is yet another goal coming from "Maven2 era" and messes up your local
repository (wrt back tracing dependencies,
https://issues.apache.org/jira/browse/MNG-7619)
I mean, if you do a build (w/o tests, or skipping most time stealing
steps), like "dry build", why is that not an option?

T


On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz  wrote:

> +1 to this list from Slawomir:
>
> - dependency:analyze /  dependency:analyze-only
> - dependency:copy
> - dependency:copy-dependencies
> - dependency:go-offline
> - dependency:list
> - dependency:tree
> - dependency:unpack
> - dependency:unpack-dependencies
>
> On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi
> > I use:
> >
> > - dependency:analyze /  dependency:analyze-only
> > - dependency:copy
> > - dependency:copy-dependencies
> > - dependency:go-offline
> > - dependency:list
> > - dependency:tree
> > - dependency:unpack
> > - dependency:unpack-dependencies
> >
> >
> >
> > czw., 21 mar 2024 o 17:06 Tamás Cservenák 
> > napisał(a):
> >
> > > Howdy,
> > >
> > > I'd would be interested in how users and devs are using
> > > maven-dependency-plugin:
> > > https://maven.apache.org/plugins/maven-dependency-plugin/
> > >
> > > I collected some basic questions I'd like to have answered (but feel
> free
> > > to add more info!):
> > > - which goals are "must have" for you
> > > - which goals are "I never touched" for you (or, "I really don't need"
> or
> > > "never used" or "shrug")
> > > - what is missing?
> > >
> > > Thanks
> > > T
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: [DISCUSS] Maven Dependency Plugin

Agreed,
Use of "purge-local-repository" is a very bad thing (next to "go offline"
and related goals).
They all come from the "maven2 era", and should never be used with Maven3...

T

On Thu, Mar 21, 2024 at 7:50 PM Richard Eckart de Castilho 
wrote:

>
> > On 21. Mar 2024, at 19:43, Tamás Cservenák  wrote:
> >
> > I mean, I know what those goals do, I am just unsure WHY you needed
> those.
>
> The current Apache UIMA release guidelines still list them as suggested
> steps
> to perform before a local trial build to ensure locally cached artifacts do
> not interfere with the build.
>
>   https://uima.apache.org/release.html
>
> That said, I personally do not use these goal when I run a release build
> and the new guidelines will not list them anymore - at least for the time
> being...
>
> But I'm sure people wise then I have had a reason the include them in the
> guidelines back in the day.
>
> -- Richard
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Dependency Plugin

Howdy,

Oliver: all, really?
I wonder what you used for goals like "purge-local-repository",
"resolve-plugins" etc  :)

I mean, I know what those goals do, I am just unsure WHY you needed those.

T

On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer 
wrote:

> Hi,
>
> over the time I used all of them in different projects and I think all
> of them are needed.
>
> Viele Grüße
>
> Oliver
>
>
> Am 21.03.24 um 17:04 schrieb Tamás Cservenák:
> > Howdy,
> >
> > I'd would be interested in how users and devs are using
> > maven-dependency-plugin:
> > https://maven.apache.org/plugins/maven-dependency-plugin/
> >
> > I collected some basic questions I'd like to have answered (but feel free
> > to add more info!):
> > - which goals are "must have" for you
> > - which goals are "I never touched" for you (or, "I really don't need" or
> > "never used" or "shrug")
> > - what is missing?
> >
> > Thanks
> > T
> >
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[DISCUSS] Maven Dependency Plugin

Howdy,

I'd would be interested in how users and devs are using
maven-dependency-plugin:
https://maven.apache.org/plugins/maven-dependency-plugin/

I collected some basic questions I'd like to have answered (but feel free
to add more info!):
- which goals are "must have" for you
- which goals are "I never touched" for you (or, "I really don't need" or
"never used" or "shrug")
- what is missing?

Thanks
T

[ANN] Apache Maven GPG Plugin 3.2.1 Released

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

Howdy,

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

This release is a bugfix, restoring plugin ability to pick up GPG
passphrase from settings.xml. Have to be noted though, that this method of
getting passphrases is considered "bad practice".

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


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

** Bug
* [MGPG-112] - Upgrading from 3.1.0 to 3.2.0 with no other changes
causes "gpg: signing failed: No pinentry"
** Dependency upgrade
* [MGPG-111] - Clean up dependency declarations

Have fun,
-The Apache Maven team

[ANN] Apache Maven 4.0.0-alpha-13 released

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

The Apache Maven team is pleased to announce the release of
Apache Maven 4.0.0-alpha-13

Note: This is the first release that requires Java 17!

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-alpha-13 is available via https://maven.apache.org/download.cgi

This is an alpha release, not suitable for production. If you hit any
problem,
please raise a JIRA issue or send an email to the mailing list.

Notable changes include:
- requires Java 17 as “minimum runtime Java requirement”
- brings the latest Maven Resolver 2.0.0-alpha-8
- new features like Profile OS activation with wildcards, Profile
activation by packaging, SPI for user properties
- improvements related to dependencyManagement and BOM handling, new APIs
for “dependency path control”
- and many bug fixes since alpha-12

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

Have fun!
The Apache Maven Team

[ANN] Release Maven Remote Resources Plugin 3.2.0

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

Howdy,

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

https://maven.apache.org/plugins/maven-remote-resources-plugin/

Release Notes - Maven Remote Resources Plugin - Version 3.2.0

** Bug
* [MRRESOURCES-135] - Show projectTimespan year in UTC
** Improvement
* [MRRESOURCES-145] - Avoid overwriting the generated file with the
same content
** Dependency upgrade
* [MRRESOURCES-136] - Upgrade Parent to 41
* [MRRESOURCES-137] - Bump commons-io from 2.11.0 to 2.13.0
* [MRRESOURCES-138] - Bump maven-filtering from 3.3.0 to 3.3.1
* [MRRESOURCES-139] - Bump maven-archiver from 3.6.0 to 3.6.1
* [MRRESOURCES-140] - Bump plexus-utils from 3.5.1 to 4.0.0 and
plexus-xml 3.0.0
* [MRRESOURCES-142] - Bump commons-io from 2.13.0 to 2.15.1
* [MRRESOURCES-143] - Maven 3.6.3 as minimum requirements
* [MRRESOURCES-144] - Bump org.codehaus.plexus:plexus-resources from
1.2.0 to 1.3.0

Have fun,
-The Apache Maven team

[ANN] Maven Filtering 3.3.2 Released

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

Howdy,

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

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

https://maven.apache.org/shared/maven-filtering/download.cgi

Release Notes - Maven Shared Components - Version maven-filtering-3.3.2

** Bug
* [MSHARED-1050] - ConcurrentModificationException  for maven-filtering
* [MSHARED-1285] - DefaultMavenResourcesFiltering uses BuildContext in
a way that fails sometimes
* [MSHARED-1330] - Incremental builds fail on filtered read-only
resources
** Improvement
* [MSHARED-1216] - Use a caching output stream when filtering resources
* [MSHARED-1351] - Confusing message when copying resources from
project's baseDir
** Dependency upgrade
* [MSHARED-1214] - SVN tag in pom.xml
* [MSHARED-1339] - Upgrade parent POM to version 41
* [MSHARED-1340] - Require Maven 3.6.3+
* [MSHARED-1341] - Convert tests to Junit 5

Have fun,
-The Apache Maven team

[ANN] Apache Maven GPG Plugin 3.2.0 Released

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

Howdy,

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

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


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

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

Release Notes - Maven GPG Plugin - Version 3.2.0

** Bug
* [MGPG-85] - Regression in maven-metadata for SNAPSHOTs between 1.6
and 3.0.1
* [MGPG-98] - non-reproducible pom.xml
* [MGPG-99] - Passcode byte array provided to gpg executable on stdin
is not terminated
* [MGPG-100] - Fix Temporary File Information Disclosure Vulnerability
** New Feature
* [MGPG-106] - Introduce second signer implementation based on Bouncy
Castle
** Improvement
* [MGPG-101] - Switch to Junit5
* [MGPG-102] - Drop maven-artifact-transfer used by sign-and-deploy-file
* [MGPG-105] - Stop propagating bad practices; but allow for "compat
mode"
* [MGPG-110] - The sign-and-deploy-file mojo POM validation is off
** Task
* [MGPG-103] - Fix Windows CI
* [MGPG-107] - Settle on JUnit 5 assertions
* [MGPG-108] - Update plugin site doco
** Dependency upgrade
* [MGPG-104] - Update to 3.9.6, drop the cruft, minimum baseline
remains 3.2.5

Have fun,
-The Apache Maven team

Re: [VOTE] Require Java 17 for Maven 4

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

+1

On Wed, Feb 28, 2024, 08:31 Benjamin Marwell  wrote:

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

Re: Failed to init Classpath for jar file C:\apache-maven-3.9.6\boot\plexus-classworlds.license during compilation

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

Howdy,

Can you post debug output how the compiler plugin is invoked?

Also, looks related:
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1578

T

On Fri, Mar 1, 2024 at 10:37 AM Václav Haisman  wrote:

> I am getting the following error during build with Maven 3.9.6 and Java 21.
> The effective POM part for the compiler plugin is below the exception
> trace. Is this a known issue?
>
> [INFO] --- compiler:3.12.1:compile (default-compile) @ apmservices.artemis
> ---
> [INFO] Recompiling the module because of changed source code.
> [INFO] Compiling with eclipse [debug:lines,vars,source parameters release
> 21] to target\classes
> *Failed to init Classpath for jar file
> C:\apache-maven-3.9.6\boot\plexus-classworlds.license*
> java.util.zip.ZipException: zip END header not found
> at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1649)
> at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
> at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1495)
> at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
> at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:724)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:251)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:180)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:194)
> at
>
> org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:204)
> at
>
> org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
> at
>
> org.eclipse.jdt.internal.compiler.batch.FileSystem.(FileSystem.java:233)
> at
>
> org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3480)
> at
>
> org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4726)
> at
>
> org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.call(EclipseCompilerImpl.java:101)
> at
>
> org.eclipse.jdt.internal.compiler.tool.EclipseCompiler$1.call(EclipseCompiler.java:196)
> at
>
> org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler.performCompile(EclipseJavaCompiler.java:307)
> at
>
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1188)
> at
>
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:212)
> at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
>
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:53)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:206)
> at
>
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:283)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:226)
> at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:407)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:348)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
>
> Effective POM section:
>
>   
> maven-compiler-plugin
> 3.12.1
> 
>   
> default-compile
> compile
> 
>   compile
> 
> 
>   21
>   21
>   21
>   eclipse
>   true
>   true
>   lines,vars,source
>   
> -properties
>
>
>

Re: a question about the Maven Resolver Ant Tasks uber JAR

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

Re-reading your "I tried to make a JAR that included the Maven Resolver Ant
Tasks uber JAR plus some extra stuff"...

The Maven Resolver Ant Tasks uber JAR contains _relocated_ classes (see
POM).

Hence, using this uber JAR to create another uber JAR is not recommended
(or make sure there are no shared dependencies).

You'd be better if you used non-uber JAR dependencies of Ant Tasks and
other stuff and create uber jar out of those instead.

T

On Fri, Mar 1, 2024 at 4:55 PM Alan Snyder 
wrote:

> So how should this issue be resolved?
>
> Should the exclusion be removed?
>
> > On Feb 28, 2024, at 9:33 PM, Thorsten Heit  wrote:
> >
> > Hi,
> >
> >> For reasons that I may no longer believe, I tried to make a JAR that
> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
> >> I figured I could do that by resolving the Maven Resolver Ant Tasks and
> including all those artifacts in my JAR.
> >> But that did not work.
> >> The resulting JAR fails because of a class not found:
> org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
> >> What seems odd is that the POM for maven-resolver-transport-http
> *explicitly excludes commons-logging*.
> >> The stated explanation is that jcl-over-slf4j is used instead.
> >> But obviously, there is some need for commons-logging, and the MRAT
> uber JAR includes commons-logging.
> >> Is commons-logging added to the MRAT uber JAR as a special case?
> >
> > As long as *jcl-over-slf4j* itself is included, that explains the
> > presence of commons-logging stuff:
> >
> >
> > % jar tf
> > ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar
> > | sort
> > META-INF/
> > (...)
> > org/
> > org/apache/
> > org/apache/commons/
> > org/apache/commons/logging/
> > org/apache/commons/logging/Log.class
> > org/apache/commons/logging/LogConfigurationException.class
> > org/apache/commons/logging/LogFactory.class
> > org/apache/commons/logging/impl/
> > org/apache/commons/logging/impl/NoOpLog.class
> > org/apache/commons/logging/impl/SLF4JLocationAwareLog.class
> > org/apache/commons/logging/impl/SLF4JLog.class
> > org/apache/commons/logging/impl/SLF4JLogFactory.class
> > org/apache/commons/logging/impl/SimpleLog.class
> >
> >
> > Regards
> >
> > Thorsten
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: problem resolving LATEST dependency in the local repo

Correct!
It says "Maven 3.x no longer supports usage of these metaversions in the
POM"

T

On Thu, Feb 29, 2024 at 4:04 PM Alan Snyder 
wrote:

> The Maven 3 compatibility notes page can be read as saying that RELEASE
> and LATEST are deprecated only for finding plugins, although it can also be
> read as a general statement.
>
> Which is the correct interpretation?
>
> I quote:
>
> Given the threat of non-reproducible builds imposed by automatic plugin
> version resolution, this feature is scheduled for removal as far as plugin
> declarations in the POM are concerned.
> Internally, Maven 2.x used the special version markers RELEASE and LATEST
> to support automatic plugin version resolution. These metaversions were
> also recognized in the  element for a  declaration. For
> the sake of reproducible builds, Maven 3.x no longer supports usage of
> these metaversions in the POM. As a result, users will need to replace
> occurrences of these metaversions with a concrete version.
>
> Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
>
> I understand the drawbacks of using LATEST and RELEASE, but there are
> situations where they are useful.
>
> I should have stated explicitly that LATEST is resolved correctly for
> artifacts in Maven Central.
>
>
>
> > On Feb 29, 2024, at 12:40 AM, Tamás Cservenák 
> wrote:
> >
> > Howdy,
> >
> > Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
> > They make builds non reproducible (just like snapshots): as it is a
> "moving
> > target".
> >
> > T
> >
> >
> > On Thu, Feb 29, 2024, 03:01 Alan Snyder 
> > wrote:
> >
> >> I have been using the Maven Artifact Resolver Ant Tasks with success,
> >> except in one situation:
> >>
> >> When the artifact exists only in my local repo (with version
> 1-SNAPSHOT),
> >> a dependency with version LATEST fails to resolve.
> >>
> >> An example of the error message:
> >>
> >> Could not collect dependencies: Failed to collect dependencies at
> >> org.violetlib:nls:jar:LATEST
> >>
> >> If I change the dependency to use 1-SNAPSHOT as the version, the
> resolver
> >> succeeds.
> >>
> >> Is it intentional that a local repo does not support LATEST?
> >>
> >> In case it matters, the artifact was installed in the local repo using
> mvn
> >> install:install-file.
> >>
> >>
> >>
>
>

Re: Maven resilience to interrupted install to local repository

Howdy,

am not Windows user, but we had several reports about issues, like this one:
https://issues.apache.org/jira/browse/MRESOLVER-372

T

On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov
 wrote:

> Thu, 29 Feb 2024, /Tamás Cservenák/:
>
> > Resolver 1.9.18 uses the temp file technique you describe:
> > copies to (random) temp file located in the same directory where target
> > file is, and then atomically moves the file to its place
> > (unless OS is windows, for obvious reasons).
>
> Doesn't atomic file move/replace work on Windows?  I'm using
> Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same
> technique on Windows successfully.
>
> [1]
>
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption..
> .)
> [2]
>
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE
>
> --
> Stanimir
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Publishing to Maven Central and non-OSS plugin dependencies

Howdy,

You would need to ask Sonatype about that, and check here:
https://central.sonatype.org/publish/requirements/

IMHO best to ask them about it: IIUC you want to deploy artifacts to
central that has dependencies not available from Central
(nor any other public repository?)

Thanks
T



On Thu, Feb 29, 2024 at 1:31 PM Florent Biville 
wrote:

> Hello,
>
> I'm working on an open-source project that we want to release to Maven
> Central in the coming weeks.
>
> The project currently includes a plugin dependency that is NOT open-source
> (nor in a public GitHub repository). Is that a blocker for releases to
> Maven Central? I know it would be for regular dependencies and plugins, but
> I'm not 100% sure about plugin dependencies in particular (although I would
> guess it's the same).
>
> Any input would be appreciated,
>
> Best regards,
> Florent
>

Re: Maven resilience to interrupted install to local repository

Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target
file is, and then atomically moves the file to its place
(unless OS is windows, for obvious reasons).

T

On Thu, Feb 29, 2024 at 12:17 PM Václav Haisman  wrote:

> Hi.
>
> How resilient is Maven to JVM being killed (K8s POD being killed) while it
> is installing artifact files into a local repository? Does it do the copy
> into a temporary file then rename method or does it copy into the target
> artifact file directly?
>
> --
> VH
>

Re: problem resolving LATEST dependency in the local repo

Howdy,

Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
They make builds non reproducible (just like snapshots): as it is a "moving
target".

T


On Thu, Feb 29, 2024, 03:01 Alan Snyder 
wrote:

> I have been using the Maven Artifact Resolver Ant Tasks with success,
> except in one situation:
>
> When the artifact exists only in my local repo (with version 1-SNAPSHOT),
> a dependency with version LATEST fails to resolve.
>
> An example of the error message:
>
> Could not collect dependencies: Failed to collect dependencies at
> org.violetlib:nls:jar:LATEST
>
> If I change the dependency to use 1-SNAPSHOT as the version, the resolver
> succeeds.
>
> Is it intentional that a local repo does not support LATEST?
>
> In case it matters, the artifact was installed in the local repo using mvn
> install:install-file.
>
>
>

Re: a question about the Maven Resolver Ant Tasks uber JAR

2024-02-28 Thread Tamás Cservenák

Howdy,

This is probably an oversight, as Resolver does use SLF4J and yes, in Maven
for example jcl-over-slf4j is used. Or a bug? As jcl-over-slf4j is here:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.18/maven-resolver-transport-http/pom.xml#L81-L86

Can you post some reproducer?

T

On Wed, Feb 28, 2024 at 10:50 PM Alan Snyder 
wrote:

> For reasons that I may no longer believe, I tried to make a JAR that
> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
> I figured I could do that by resolving the Maven Resolver Ant Tasks and
> including all those artifacts in my JAR.
> But that did not work.
> The resulting JAR fails because of a class not found:
> org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
> What seems odd is that the POM for maven-resolver-transport-http
> *explicitly excludes commons-logging*.
> The stated explanation is that jcl-over-slf4j is used instead.
> But obviously, there is some need for commons-logging, and the MRAT uber
> JAR includes commons-logging.
> Is commons-logging added to the MRAT uber JAR as a special case?
>
> Seems like something is wrong here.
>
> I can fix my problem by adding commons-logging explicitly to my JAR, so I
> don’t need a solution, but I would still
> like to know why I had this problem.
>
>

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

2024-02-26 Thread Tamás Cservenák

Howdy,

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

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

This is a seventh *PREVIEW* (alpha-4 was scrubbed) release of upcoming
Maven Resolver 2.0.0 meant for users of Resolver to pick it up and adapt
code if needed. This alpha contains almost all of the planned features and
improvements, and for sure some unplanned bugs as well.

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

** Bug
* [MRESOLVER-483] - PreorderNodeListGenerator bug: may print trailing
":"
** Improvement
* [MRESOLVER-421] - Extend NamedLock API to carry more than one name
* [MRESOLVER-484] - The dependencies properties should be provided by
the resolver consumer
* [MRESOLVER-493] - Support premanaged of optional, exclusions and
properties by DependencyGraphDumper
* [MRESOLVER-494] - LOCAL_PATH Artifact property really belongs to
"system" scope (or is at least very related to it)
** Task
* [MRESOLVER-480] - Update "Upgrading Resolver" page
* [MRESOLVER-491] - Get rid of last "known" scope: system
* [MRESOLVER-492] - Add toString method for
AbstractDependencyManager.Key
* [MRESOLVER-496] - Move Resolver off java.io.File to NIO2 Paths
** Dependency upgrade
* [MRESOLVER-485] - Upgrade Jetty dependency to 10.0.20
* [MRESOLVER-487] - (build) Update to exec-maven-plugin 3.1.1
* [MRESOLVER-488] - (build) Update to japicmp 0.18.3
* [MRESOLVER-489] - (build) Update m-javadoc-p to 3.6.3
* [MRESOLVER-490] - (build) Update bnd-maven-plugin to 6.4.0
* [MRESOLVER-500] - (build) Upgrade exec-maven-plugin to 3.2.0
* [MRESOLVER-501] - (build) Upgrade japicmp to 0.18.5

Have fun,
Maven Team

Re: How does maven resolve inter-module dependencies in a multi-module build?

2024-02-15 Thread Tamás Cservenák

Howdy,

usually you should consider maven build (in case maven, session == cli
invocation) as this hierarchy:
* remote repositories:
* * local repository:
* * * session

Maven will prefer things "most specific" if present:
- if is in reactor (current session), will use that
- if is in local repository (and all things like expiration etc passes)
will use that
- otherwise it goes to remote

This also implies if you want to build A and then B from _same multi module
build_ (that has let's assume modules A, B and C), ideally you
* maven install all the reactor
* maven -f A compile
etc


On Thu, Feb 15, 2024 at 9:28 PM Francois Marot 
wrote:

> to add on Joseph answer: if you are in the B directory, then only B is in
> the reactor (more or less meaning "the list of project being built by this
> Maven invocation").
> My rule of thumb is to never do that and always run from the root. If you
> want to speedup the build and you know that only B has been modified, you
> can use maven options such as:
>
> - mvn test -pl :B // it will only build/test the B module
> - mvn test -pl :B -am// it will build B and all the modules B
> depends onto
> - mvn test -rf :B// it resumes the build from B in case B's
> tests failed , so it will also build modules after B
>
> you can note that I add a semi-column before the module name because in
> case the module is a sub-module (or sub-sub-sub...module), not directly at
> the parent's root, then it is required.
> Hope this helps
>
>
> Le jeu. 15 févr. 2024 à 20:55, Joseph Leonard <
> joseph.leon...@alfasystems.com> a écrit :
>
> > Builds in the reactor are always favoured over the m2 repo because the
> > builds in the reactor will be up-to-date whereas the jar in the repo may
> be
> > out of date.
> >
> > If you run mvn compile in directory B then you will not be running a
> multi
> > module build - and therefore module A will not be in the reactor. This is
> > why the m2 repo will always be used for module A in this scenario.
> >
> > Joe
> >
> > -Original Message-
> > From: Siddharth Jain 
> > Sent: Thursday, February 15, 2024 7:50 PM
> > To: Maven Users List 
> > Subject: Re: How does maven resolve inter-module dependencies in a
> > multi-module build?
> >
> > External Email: Please be vigilant and check the contents and source for
> > signs of malicious activity.
> >
> > thanks Joe. but then if classes are available both in the target
> directory
> > of module A as well as a jar file in M2 repository which takes
> precedence?
> >
> > also i have noticed that while running mvn compile from the root works,
> > running mvn compile from the directory of B does not pick up classes from
> > A's target directory. it only picks up from M2 repo in that case.
> >
> > On Thu, Feb 15, 2024 at 11:28 AM Joseph Leonard <
> > joseph.leon...@alfasystems.com> wrote:
> >
> > > Hi Sid,
> > > It will resolve the classes directory of module A that will have been
> > > populated during module A's 'compile' build.
> > > Joe
> > >
> > > On 2024/02/15 17:50:44 Siddharth Jain wrote:
> > > > Hello,
> > > >
> > > > I am working on a multi-module Maven build. e.g., I have a root
> > > > directory containing 3 sub-projects A, B, C and a parent pom defined
> > > > in the root directory. I notice that I can run mvn compile from the
> > > > root directory
> > > and
> > > > it will build the 3 projects. The projects may have
> > > > inter-dependencies e.g., B depends on A and let's say C depends on
> > both A and B.
> > > >
> > > > My question is while building B how does maven locate the compiled
> > > > code
> > > of
> > > > A (the dependency) since maven compile by itself does not install
> > > > the
> > > built
> > > > artifact into M2 repository?
> > > >
> > > > Sid
> > > >
> > >
> >
>

Re: Versions maven plugin

2024-02-15 Thread Tamás Cservenák

Howdy,

sorry I missed this thread.

But spotted when you closed this issue, so answered there:
https://github.com/mojohaus/versions/issues/961#issuecomment-1946797974

On Sat, May 27, 2023 at 8:57 AM Andrzej  wrote:

> Hi all,
>
> I've been looking at Versions Maven Plugin and I can say that there are a
> few places that could use some refactoring.
>
> For example, VersionDetails and AbstractArtifactVersions serve several
> purposes: they seem to be both a collection of cached artifact versions,
> but at the same time store the information on the current version (unless
> they don't – like PropertyVersions which is a child of
> AbstractArtifactVersions). On top of that, they offer plenty of different
> utility methods for retrieving versions which may or not duplicate
> themselves.
>
> So, let's suppose I wanted to refactor that a little bit: is it ok to use
> Aether (like e.g. org.eclipse.aether.artifact.Artifact or
> org.eclipse.aether.version.VersionRange) API there? Or should I be looking
> somewhere else?
>
> Best regards,
> Andrzej
>

Re: Re: Re: Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

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

Howdy,

Well, sadly, Maven currently has no means to make one module "this and
that" at the same time.
It is either in the reactor or is out of it.
To me, it sounds like you want one reactor, but where module-b is "out" and
'in", at the same time (within same session)


T

On Thu, Feb 8, 2024 at 1:27 PM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hey,
> We don't need the module-b jar built in the reactor to be included in the
> war if the changes made in module-b won't affect the war. Instead, in this
> scenario, we're fine with using a jar resolved from the local repository.
> The requisites for this scenario are:
>
>   *   Any change made to module-b is only in its test tree
>   *   The only changes made to the direct and transitive dependencies of
> module-b are to its test scoped dependencies
> So basically module-b is only in the reactor for verification purposes
> rather than ‘src packaging’ purposes.
> Thanks,
> Joe
>
> On 2024/02/08 12:12:03 Tamás Cservenák wrote:
> > Hej,
> >
> > yes, basically the "hack" is well described by you:
> > - it retains "full' reactor project
> > - introduces "needs build" on project
> > - when it comes to building, it skips the project if flag set
> >
> > This results that module-b -> app link is not lost.
> > And as for your parallelization request: the truth is that there IS and
> > edge between app and module-b (via module-a), so despite module-a is
> > "done", its transitive module-b is not done, hence you cannot build these
> > two in parallel, as you do have an edge between app and module-b.
> >
> > Or to invert the question: what module-b JAR you want to have included in
> > app WAR, when building? The one built, or the one from the local
> > repository? If the latter, why are you building it in the first place?
> >
> > On Thu, Feb 8, 2024 at 12:06 PM Joseph Leonard <
> > joseph.leon...@alfasystems.com> wrote:
> >
> > > Hi Tamás,
> > > Thank you for hacking around this so rapidly. I am not familiar with
> the
> > > maven code base, so let me know if I have misinterpreted the change: Is
> > > your hack to:
> > >
> > >   1.  Retain the full multi-module build dependency graph such that the
> > > build graph always remains consistent regardless of whether a “-pl”
> arg has
> > > been provided
> > >   2.  Introduce a skip build option to satisfy the functionality of the
> > > “-pl” arg: The reactor will report the module has been built but the
> build
> > > is basically a no-op
> > > If so, this does resolve the issue but at the cost of losing the
> > > opportunity to gain extra parallelism in the build.
> > > What I was wondering may be possible (without any idea of how feasible
> it
> > > would be to implement) would be the opportunity to recognise in the
> > > multi-build distinct build graphs and then keep isolation in the
> reactor
> > > between these graphs. To elaborate, in the reproducer scenario there
> would
> > > be two distinct graphs:
> > >
> > >   *   "testsupport-module-1" followed by "app"
> > >   *   "testsupport-module-2" followed by "module-b"
> > > Ideally these two graphs build in parallel to each other and even if
> > > ultimately there is a dependency between them they NEVER resolve that
> > > dependency from within reactor they instead always resolve from the
> > > external Maven cache. The key statement here is that if a user
> presents a
> > > list of modules to be built then they really need to be sure that the
> > > DIRECT dependencies between these modules truly represent the build
> > > graph(s) they want. For tools like gitflow-incremental-builder which
> are
> > > designed to carefully work out change sets and what needs to build this
> > > offers a really powerful opportunity to optimise builds. I appreciate
> this
> > > functionality could also be seen as a gotcha (although tbf this already
> > > exists).
> > > Thanks,
> > > Joe
> > >
> > >
> > > On 2024/02/08 10:09:31 Tamás Cservenák wrote:
> > > > Seems we are on track with this. To prove my last-night theory I
> created
> > > a
> > > > "hack" (is really just that) and guess what?
> > > > It makes reproducer behave "as expected":
> > > > https://github.com/apache/maven/pull/1406
> > > >
> > > > T
> > > >
> > >

Re: Re: Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

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

Hej,

yes, basically the "hack" is well described by you:
- it retains "full' reactor project
- introduces "needs build" on project
- when it comes to building, it skips the project if flag set

This results that module-b -> app link is not lost.
And as for your parallelization request: the truth is that there IS and
edge between app and module-b (via module-a), so despite module-a is
"done", its transitive module-b is not done, hence you cannot build these
two in parallel, as you do have an edge between app and module-b.

Or to invert the question: what module-b JAR you want to have included in
app WAR, when building? The one built, or the one from the local
repository? If the latter, why are you building it in the first place?

On Thu, Feb 8, 2024 at 12:06 PM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi Tamás,
> Thank you for hacking around this so rapidly. I am not familiar with the
> maven code base, so let me know if I have misinterpreted the change: Is
> your hack to:
>
>   1.  Retain the full multi-module build dependency graph such that the
> build graph always remains consistent regardless of whether a “-pl” arg has
> been provided
>   2.  Introduce a skip build option to satisfy the functionality of the
> “-pl” arg: The reactor will report the module has been built but the build
> is basically a no-op
> If so, this does resolve the issue but at the cost of losing the
> opportunity to gain extra parallelism in the build.
> What I was wondering may be possible (without any idea of how feasible it
> would be to implement) would be the opportunity to recognise in the
> multi-build distinct build graphs and then keep isolation in the reactor
> between these graphs. To elaborate, in the reproducer scenario there would
> be two distinct graphs:
>
>   *   "testsupport-module-1" followed by "app"
>   *   "testsupport-module-2" followed by "module-b"
> Ideally these two graphs build in parallel to each other and even if
> ultimately there is a dependency between them they NEVER resolve that
> dependency from within reactor they instead always resolve from the
> external Maven cache. The key statement here is that if a user presents a
> list of modules to be built then they really need to be sure that the
> DIRECT dependencies between these modules truly represent the build
> graph(s) they want. For tools like gitflow-incremental-builder which are
> designed to carefully work out change sets and what needs to build this
> offers a really powerful opportunity to optimise builds. I appreciate this
> functionality could also be seen as a gotcha (although tbf this already
> exists).
> Thanks,
> Joe
>
>
> On 2024/02/08 10:09:31 Tamás Cservenák wrote:
> > Seems we are on track with this. To prove my last-night theory I created
> a
> > "hack" (is really just that) and guess what?
> > It makes reproducer behave "as expected":
> > https://github.com/apache/maven/pull/1406
> >
> > T
> >
> > On Wed, Feb 7, 2024 at 10:05 PM Tamás Cservenák 
> wrote:
> >
> > > Howdy,
> > >
> > > Thank you very much, the reproducer works. Did not dig thru it fully,
> but
> > > here are some related issues:
> > >
> > > https://issues.apache.org/jira/browse/MNG-8028 (funny thing, I created
> > > this few weeks ago)
> > > https://issues.apache.org/jira/browse/MNG-6300
> > >
> > > Will report back tomorrow (EU TZ)
> > > T
> > >
> > >
> > > On Wed, Feb 7, 2024 at 7:48 PM Joseph Leonard <
> > > joseph.leon...@alfasystems.com> wrote:
> > >
> > >> Hi Tamás,
> > >> I have created a simple example here:
> > >> https://github.com/josple/mvn-multibuild-issue
> > >> Hopefully the README is clear enough – let me know if I can clarify
> > >> anything.
> > >> Thanks,
> > >> Joe
> > >>
> > >> On 2024/02/07 17:33:08 Tamás Cservenák wrote:
> > >> > Howdy,
> > >> >
> > >> > In that case, there is something fishy with the project, my blind
> guess
> > >> > would be some "hidden" inter-module dependency maybe?
> > >> >
> > >> > Can you provide access to source, or, if not feasible, could you
> provide
> > >> > some reproducer and publish it on Github/Gitlab/whatever (maybe even
> > >> just
> > >> > send it privately as ML strips off attachments and images) for us
> to see
> > >> > this in action?
> > >> >
> > >> > Thanks

Re: Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

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

Seems we are on track with this. To prove my last-night theory I created a
"hack" (is really just that) and guess what?
It makes reproducer behave "as expected":
https://github.com/apache/maven/pull/1406

T

On Wed, Feb 7, 2024 at 10:05 PM Tamás Cservenák  wrote:

> Howdy,
>
> Thank you very much, the reproducer works. Did not dig thru it fully, but
> here are some related issues:
>
> https://issues.apache.org/jira/browse/MNG-8028 (funny thing, I created
> this few weeks ago)
> https://issues.apache.org/jira/browse/MNG-6300
>
> Will report back tomorrow (EU TZ)
> T
>
>
> On Wed, Feb 7, 2024 at 7:48 PM Joseph Leonard <
> joseph.leon...@alfasystems.com> wrote:
>
>> Hi Tamás,
>> I have created a simple example here:
>> https://github.com/josple/mvn-multibuild-issue
>> Hopefully the README is clear enough – let me know if I can clarify
>> anything.
>> Thanks,
>> Joe
>>
>> On 2024/02/07 17:33:08 Tamás Cservenák wrote:
>> > Howdy,
>> >
>> > In that case, there is something fishy with the project, my blind guess
>> > would be some "hidden" inter-module dependency maybe?
>> >
>> > Can you provide access to source, or, if not feasible, could you provide
>> > some reproducer and publish it on Github/Gitlab/whatever (maybe even
>> just
>> > send it privately as ML strips off attachments and images) for us to see
>> > this in action?
>> >
>> > Thanks
>> > T
>> >
>> > On Wed, Feb 7, 2024 at 6:29 PM Joseph Leonard <
>> > joseph.leon...@alfasystems.com> wrote:
>> >
>> > > Hi Tamás,
>> > > We have previously played around a bit with mvnd but not takari
>> directly –
>> > > I will have a play with it. With regards to this issue, using the
>> takari
>> > > smart builder unfortunately doesn’t resolve the issue.
>> > > Joe
>> > >
>> > > On 2024/02/07 11:41:22 Tamás Cservenák wrote:
>> > > > Can you please try smart builder instead?
>> > > > https://github.com/takari/takari-smart-builder
>> > > >
>> > > > (note: smart builder is used by mvnd as well)
>> > > >
>> > > > The difference between the two can be seen here:
>> > > > http://takari.io/book/30-team-maven.html#takari-smart-builder
>> > > >
>> > > > On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
>> > > > joseph.leon...@alfasystems.com> wrote:
>> > > >
>> > > > > Hi Tamás,
>> > > > > Yeah, this was unexpected to me initially as well. From what I
>> can tell
>> > > > > the Maven reactor only considers direct dependencies (i.e. not
>> > > transitive
>> > > > > dependencies) between the modules in the reactor when working out
>> the
>> > > build
>> > > > > graph. For example if you have a simple linear dependency chain
>> of:
>> > > > > One --> Two --> Three --> Four --> Five
>> > > > > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will
>> result
>> > > in
>> > > > > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]).
>> I
>> > > assume
>> > > > > this is as designed because it actually offers quite powerful
>> > > functionality
>> > > > > to improve the parallelism in your build. An example of where
>> this is
>> > > legit
>> > > > > is when:
>> > > > >
>> > > > >   *   “Four” has a test scope dependency on “Five”
>> > > > >   *   “One” has a test scoped dependency on “Two”
>> > > > > If you made a src code change to “Five” and “Two” then it would be
>> > > safe to
>> > > > > build [One,Two] and [Four,Five] in parallel because you know the
>> > > changes
>> > > > > within these graphs cannot impact each other.
>> > > > > Joe
>> > > > >
>> > > > > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
>> > > > > > Howdy,
>> > > > > >
>> > > > > > To me this looks like Maven is not aware that the App depends on
>> > > > > ModuleB...
>> > > > > > Are they "plain dependency" linked? Or what kind of dependency
>> we
>> > > talk
>> > > > > > about here?
>> > &

Re: Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Howdy,

Thank you very much, the reproducer works. Did not dig thru it fully, but
here are some related issues:

https://issues.apache.org/jira/browse/MNG-8028 (funny thing, I created this
few weeks ago)
https://issues.apache.org/jira/browse/MNG-6300

Will report back tomorrow (EU TZ)
T


On Wed, Feb 7, 2024 at 7:48 PM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi Tamás,
> I have created a simple example here:
> https://github.com/josple/mvn-multibuild-issue
> Hopefully the README is clear enough – let me know if I can clarify
> anything.
> Thanks,
> Joe
>
> On 2024/02/07 17:33:08 Tamás Cservenák wrote:
> > Howdy,
> >
> > In that case, there is something fishy with the project, my blind guess
> > would be some "hidden" inter-module dependency maybe?
> >
> > Can you provide access to source, or, if not feasible, could you provide
> > some reproducer and publish it on Github/Gitlab/whatever (maybe even just
> > send it privately as ML strips off attachments and images) for us to see
> > this in action?
> >
> > Thanks
> > T
> >
> > On Wed, Feb 7, 2024 at 6:29 PM Joseph Leonard <
> > joseph.leon...@alfasystems.com> wrote:
> >
> > > Hi Tamás,
> > > We have previously played around a bit with mvnd but not takari
> directly –
> > > I will have a play with it. With regards to this issue, using the
> takari
> > > smart builder unfortunately doesn’t resolve the issue.
> > > Joe
> > >
> > > On 2024/02/07 11:41:22 Tamás Cservenák wrote:
> > > > Can you please try smart builder instead?
> > > > https://github.com/takari/takari-smart-builder
> > > >
> > > > (note: smart builder is used by mvnd as well)
> > > >
> > > > The difference between the two can be seen here:
> > > > http://takari.io/book/30-team-maven.html#takari-smart-builder
> > > >
> > > > On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
> > > > joseph.leon...@alfasystems.com> wrote:
> > > >
> > > > > Hi Tamás,
> > > > > Yeah, this was unexpected to me initially as well. From what I can
> tell
> > > > > the Maven reactor only considers direct dependencies (i.e. not
> > > transitive
> > > > > dependencies) between the modules in the reactor when working out
> the
> > > build
> > > > > graph. For example if you have a simple linear dependency chain of:
> > > > > One --> Two --> Three --> Four --> Five
> > > > > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will
> result
> > > in
> > > > > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I
> > > assume
> > > > > this is as designed because it actually offers quite powerful
> > > functionality
> > > > > to improve the parallelism in your build. An example of where this
> is
> > > legit
> > > > > is when:
> > > > >
> > > > >   *   “Four” has a test scope dependency on “Five”
> > > > >   *   “One” has a test scoped dependency on “Two”
> > > > > If you made a src code change to “Five” and “Two” then it would be
> > > safe to
> > > > > build [One,Two] and [Four,Five] in parallel because you know the
> > > changes
> > > > > within these graphs cannot impact each other.
> > > > > Joe
> > > > >
> > > > > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > > > > > Howdy,
> > > > > >
> > > > > > To me this looks like Maven is not aware that the App depends on
> > > > > ModuleB...
> > > > > > Are they "plain dependency" linked? Or what kind of dependency we
> > > talk
> > > > > > about here?
> > > > > > In short: why would App start while ModuleB (upstream dep) is not
> > > done?
> > > > > > Something is fishy here.
> > > > > >
> > > > > > T
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > > > > > joseph.leon...@alfasystems.com> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > It would be great to ge

Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Howdy,

In that case, there is something fishy with the project, my blind guess
would be some "hidden" inter-module dependency maybe?

Can you provide access to source, or, if not feasible, could you provide
some reproducer and publish it on Github/Gitlab/whatever (maybe even just
send it privately as ML strips off attachments and images) for us to see
this in action?

Thanks
T

On Wed, Feb 7, 2024 at 6:29 PM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi Tamás,
> We have previously played around a bit with mvnd but not takari directly –
> I will have a play with it. With regards to this issue, using the takari
> smart builder unfortunately doesn’t resolve the issue.
> Joe
>
> On 2024/02/07 11:41:22 Tamás Cservenák wrote:
> > Can you please try smart builder instead?
> > https://github.com/takari/takari-smart-builder
> >
> > (note: smart builder is used by mvnd as well)
> >
> > The difference between the two can be seen here:
> > http://takari.io/book/30-team-maven.html#takari-smart-builder
> >
> > On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
> > joseph.leon...@alfasystems.com> wrote:
> >
> > > Hi Tamás,
> > > Yeah, this was unexpected to me initially as well. From what I can tell
> > > the Maven reactor only considers direct dependencies (i.e. not
> transitive
> > > dependencies) between the modules in the reactor when working out the
> build
> > > graph. For example if you have a simple linear dependency chain of:
> > > One --> Two --> Three --> Four --> Five
> > > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result
> in
> > > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I
> assume
> > > this is as designed because it actually offers quite powerful
> functionality
> > > to improve the parallelism in your build. An example of where this is
> legit
> > > is when:
> > >
> > >   *   “Four” has a test scope dependency on “Five”
> > >   *   “One” has a test scoped dependency on “Two”
> > > If you made a src code change to “Five” and “Two” then it would be
> safe to
> > > build [One,Two] and [Four,Five] in parallel because you know the
> changes
> > > within these graphs cannot impact each other.
> > > Joe
> > >
> > > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > > > Howdy,
> > > >
> > > > To me this looks like Maven is not aware that the App depends on
> > > ModuleB...
> > > > Are they "plain dependency" linked? Or what kind of dependency we
> talk
> > > > about here?
> > > > In short: why would App start while ModuleB (upstream dep) is not
> done?
> > > > Something is fishy here.
> > > >
> > > > T
> > > >
> > > >
> > > > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > > > joseph.leon...@alfasystems.com> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > It would be great to get any thoughts on whether the following is a
> > > defect:
> > > > >
> > > > >
> > > > > Issue details:
> > > > > tl;dr
> > > > >
> > > > > Maven can resolve dependencies either from:
> > > > >
> > > > >   *   an external repo
> > > > >   *   a class directory of a module being built within the reactor
> > > > >   *   a packaged jar of a module being built within the reactor
> > > > >
> > > > > If you run a concurrent multi-module build it is possible to get a
> race
> > > > > condition whereby the build of module Foo may resolve module Bar
> from
> > > > > either of the three resolution channels. This inconsistency can
> result
> > > in
> > > > > the Maven war plugin sometimes failing to build a functional war
> file.
> > > I
> > > > > would expect a consistent resolution would always take place.
> > > > >
> > > > > Full details
> > > > > Scenario
> > > > >
> > > > > Consider you have a repo with the following structure:
> > > > >
> > > > >App
> > > > >
> > > > >  / \
> > > > >
> > > > > /   \
> > > > >
> > > > >(compile scope)  (test scope)
> &g

Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Howdy,

see here
https://maven.apache.org/mailing-lists.html

On Wed, Feb 7, 2024 at 12:55 PM Amn Ojee Uw  wrote:

> How can I unsubscribe from this mailing list?
> Thanks in advance.
>
> *ArbolOne
> Using Fire Fox and Thunderbird.
> Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
> platform has been exciting and most rewarding.
> [ Ñ ]*
>
>
>
> On Wed, Feb 7, 2024 at 5:50 AM Joseph Leonard <
> joseph.leon...@alfasystems.com> wrote:
>
> > Hi Tamás,
> > Yeah, this was unexpected to me initially as well. From what I can tell
> > the Maven reactor only considers direct dependencies (i.e. not transitive
> > dependencies) between the modules in the reactor when working out the
> build
> > graph. For example if you have a simple linear dependency chain of:
> > One --> Two --> Three --> Four --> Five
> > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result in
> > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I
> assume
> > this is as designed because it actually offers quite powerful
> functionality
> > to improve the parallelism in your build. An example of where this is
> legit
> > is when:
> >
> >   *   “Four” has a test scope dependency on “Five”
> >   *   “One” has a test scoped dependency on “Two”
> > If you made a src code change to “Five” and “Two” then it would be safe
> to
> > build [One,Two] and [Four,Five] in parallel because you know the changes
> > within these graphs cannot impact each other.
> > Joe
> >
> > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > > Howdy,
> > >
> > > To me this looks like Maven is not aware that the App depends on
> > ModuleB...
> > > Are they "plain dependency" linked? Or what kind of dependency we talk
> > > about here?
> > > In short: why would App start while ModuleB (upstream dep) is not done?
> > > Something is fishy here.
> > >
> > > T
> > >
> > >
> > > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > > joseph.leon...@alfasystems.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > It would be great to get any thoughts on whether the following is a
> > defect:
> > > >
> > > >
> > > > Issue details:
> > > > tl;dr
> > > >
> > > > Maven can resolve dependencies either from:
> > > >
> > > >   *   an external repo
> > > >   *   a class directory of a module being built within the reactor
> > > >   *   a packaged jar of a module being built within the reactor
> > > >
> > > > If you run a concurrent multi-module build it is possible to get a
> race
> > > > condition whereby the build of module Foo may resolve module Bar from
> > > > either of the three resolution channels. This inconsistency can
> result
> > in
> > > > the Maven war plugin sometimes failing to build a functional war
> file.
> > I
> > > > would expect a consistent resolution would always take place.
> > > >
> > > > Full details
> > > > Scenario
> > > >
> > > > Consider you have a repo with the following structure:
> > > >
> > > >App
> > > >
> > > >  / \
> > > >
> > > > /   \
> > > >
> > > >(compile scope)  (test scope)
> > > >
> > > >   /   \
> > > >
> > > > \/_   _\/
> > > >
> > > >  ModuleA  TestSupportModule1
> > > >
> > > > /
> > > >
> > > >/
> > > >
> > > > (compile scope)
> > > >
> > > >  /
> > > >
> > > >\/_
> > > >
> > > > ModuleB
> > > >
> > > >/
> > > >
> > > >   /
> > > >
> > > > (test scope)
> > > >
> > > > /
> > > >
> > > >   \/_
> > > >
> > > > TestSupportModule2
> > > >
> > > > If you were to make a src code change to the following test support
> > > > modules:
> > > >
> > > >   *   TestSupportModule1
> > > >   *   Test

Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Can you please try smart builder instead?
https://github.com/takari/takari-smart-builder

(note: smart builder is used by mvnd as well)

The difference between the two can be seen here:
http://takari.io/book/30-team-maven.html#takari-smart-builder

On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi Tamás,
> Yeah, this was unexpected to me initially as well. From what I can tell
> the Maven reactor only considers direct dependencies (i.e. not transitive
> dependencies) between the modules in the reactor when working out the build
> graph. For example if you have a simple linear dependency chain of:
> One --> Two --> Three --> Four --> Five
> Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result in
> two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I assume
> this is as designed because it actually offers quite powerful functionality
> to improve the parallelism in your build. An example of where this is legit
> is when:
>
>   *   “Four” has a test scope dependency on “Five”
>   *   “One” has a test scoped dependency on “Two”
> If you made a src code change to “Five” and “Two” then it would be safe to
> build [One,Two] and [Four,Five] in parallel because you know the changes
> within these graphs cannot impact each other.
> Joe
>
> On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > Howdy,
> >
> > To me this looks like Maven is not aware that the App depends on
> ModuleB...
> > Are they "plain dependency" linked? Or what kind of dependency we talk
> > about here?
> > In short: why would App start while ModuleB (upstream dep) is not done?
> > Something is fishy here.
> >
> > T
> >
> >
> > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > joseph.leon...@alfasystems.com> wrote:
> >
> > > Hi all,
> > >
> > > It would be great to get any thoughts on whether the following is a
> defect:
> > >
> > >
> > > Issue details:
> > > tl;dr
> > >
> > > Maven can resolve dependencies either from:
> > >
> > >   *   an external repo
> > >   *   a class directory of a module being built within the reactor
> > >   *   a packaged jar of a module being built within the reactor
> > >
> > > If you run a concurrent multi-module build it is possible to get a race
> > > condition whereby the build of module Foo may resolve module Bar from
> > > either of the three resolution channels. This inconsistency can result
> in
> > > the Maven war plugin sometimes failing to build a functional war file.
> I
> > > would expect a consistent resolution would always take place.
> > >
> > > Full details
> > > Scenario
> > >
> > > Consider you have a repo with the following structure:
> > >
> > >App
> > >
> > >  / \
> > >
> > > /   \
> > >
> > >(compile scope)  (test scope)
> > >
> > >   /   \
> > >
> > > \/_   _\/
> > >
> > >  ModuleA  TestSupportModule1
> > >
> > > /
> > >
> > >/
> > >
> > > (compile scope)
> > >
> > >  /
> > >
> > >\/_
> > >
> > > ModuleB
> > >
> > >/
> > >
> > >   /
> > >
> > > (test scope)
> > >
> > > /
> > >
> > >   \/_
> > >
> > > TestSupportModule2
> > >
> > > If you were to make a src code change to the following test support
> > > modules:
> > >
> > >   *   TestSupportModule1
> > >   *   TestSupportModule2
> > >
> > > Then the minimum number of modules we need to build to verify the
> change
> > > set is OK is:
> > >
> > >   *   TestSupportModule1
> > >   *   TestSupportModule2
> > >   *   ModuleB
> > >   *   App
> > >
> > > i.e. there is no requirement to build ModuleA because we know that
> none of
> > > the src code changes could impact the classpaths used in its maven
> build.
> > >
> > > We know that despite 'App' depending (transitively) on ModuleB there
> is no
> > > need for the 'App' build to wait for ModuleB to complete its build
> because
> > > th

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Tamás Cservenák

Howdy,

To me this looks like Maven is not aware that the App depends on ModuleB...
Are they "plain dependency" linked? Or what kind of dependency we talk
about here?
In short: why would App start while ModuleB (upstream dep) is not done?
Something is fishy here.

T


On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race
> condition whereby the build of module Foo may resolve module Bar from
> either of the three resolution channels. This inconsistency can result in
> the Maven war plugin sometimes failing to build a functional war file. I
> would expect a consistent resolution would always take place.
>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support
> modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change
> set is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of
> the src code changes could impact the classpaths used in its maven build.
>
> We know that despite 'App' depending (transitively) on ModuleB there is no
> need for the 'App' build to wait for ModuleB to complete its build because
> the src code change to TestSupportModule2 will not impact any of the
> classpaths used in the App maven build. Therefore to get the most efficient
> build possible we ideally would invoke Maven to run with 2 threads and with
> instruction to build two distinct 'dependency graphs':
>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the
> reactor build order is based only on the direct (i.e. non-transitive)
> dependencies of the modules provided to the reactor in the build command.
> Therefore the absence of ModuleA results in two distinct 'dependency
> graphs':
>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with
> 100s of modules and this type of build optimisation makes a significant
> difference to the speed of our monobuild (we use
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> to automate the logic of determining which modules to include in the
> reactor based on our change set).
>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build
> has a race condition with the ModuleB build which will result in one of the
> following three outcomes:
>
>   *   If the 'App' build starts before the ModuleB build has compiled its
> src classes then the 'App' build will resolve ModuleB from the external
> repo (i.e. equivalent to ModuleB not being in the reactor at all)
>   *   If the 'App' build starts after ModuleB has compiled its src classes
> but before it has packaged these classes into a jar then the 'App' build
> will resolve ModuleB's target/classes directory
>   *   If the 'App' build starts after ModuleB has packaged its jar file
> then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
>
> In many scenarios this dependency resolution inconsistency doesn't
> represent a challenge. However, it does cause an issue in our case because
> the 'App' POM has its Maven packaging stanza configured to war and in the
> scenario where ModuleB's target/classes directory is resolved by the 'App'
> then this results in the resultant 'App' war file being packaged with a
> completely empty ModuleB.jar file.
>
> Proposed solution
>
> Ideally we would like the Maven reactor to retain isolation between the
> two distinct 'dependency graphs' it constructs at instantiation throughout
> the entire Maven build. This would mean, in the simple example above, that
> the 'App' would always resolves ModuleB from the external repo (regardless
> of whether the reactor has built ModuleB or not in a separate 'dependency
> graph' in

Re: How to know which plugin/goal is frozen in multithreaded build ?

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

Howdy,


Important questions:
- what maven version exactly
- what java version are you using?
- how exactly is "multi threaded" build invoked

Also, you could tweak logging properties to show threads and trigger MT
build in debug piped into file, and that file when filtered for thread name
would probably give some clue.

T

On Sat, Feb 3, 2024, 17:48 Francois Marot  wrote:

> Hello all,
>
> I have a large build that completes normally in single threaded build but
> freezes in multithreaded builds. Problem is I do not know which module and
> which plugin is frozen. The last logs that get displayed are the classic
> end log for a given module and the logs always stop there. So I believe
> another module is still underway, stuck, and prevents the build to go
> further. If there were entry/exit logs for each module and each plugin, I
> could parse the logs, match each entry/exit, and find the last missing
> exit. That would point me to the culprit...
> But to my knowledge there are no such entry/exit logs...
>
> I'will try to use mvnDebug command and plug a debugger but I do not even
> know what I'm looking for ! Any idea ?
>
> Have a good day
> François
>

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

2024-01-29 Thread Tamás Cservenák

Howdy,

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

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

This is a sixth *PREVIEW* (alpha-4 was scrubbed) release of upcoming Maven
Resolver 2.0.0 meant for users of Resolver to pick it up and adapt code if
needed. This alpha contains almost all of the planned features and
improvements, and for sure some unplanned bugs as well.

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

** Bug
* [MRESOLVER-334] - Maven Resolver GenericVersionScheme diverges from
the spec
* [MRESOLVER-336] - Unexpected handling of qualifiers in
GenericVersionScheme
* [MRESOLVER-464] - JDK transport bug
** Improvement
* [MRESOLVER-264] - Make file-lock the default locking
* [MRESOLVER-463] - Ensure checksum record file (summary fie) is sorted
by artifact relative path and not checksum
* [MRESOLVER-465] - Make room for new version scheme implementations
* [MRESOLVER-467] - Pull out shared HTTP (Remote Included checksum) code
* [MRESOLVER-468] - Stabilize supplier binary and source compatibility
** Task
* [MRESOLVER-466] - Extend site documentation
* [MRESOLVER-470] - Prepare for new changes regarding Artifact
properties/scopes
* [MRESOLVER-471] - Resolver should be oblivious about scopes
** Dependency upgrade
* [MRESOLVER-469] - Upgrade to Maven 4.0.0-alpha-12
* [MRESOLVER-472] - Upgrade Jetty dependency to 10.0.19
* [MRESOLVER-473] - Upgrade slf4j to version 2.0.11 (align with Maven)
* [MRESOLVER-474] - Upgrade (build, not project) dependency
commons-lang to 3.14.0
* [MRESOLVER-475] - Upgrade Wagon transport dependency:
plexus-classworlds to 2.8.0
* [MRESOLVER-476] - Upgrade Wagon transport test dependency:
plexus-testing to 1.3.0
* [MRESOLVER-477] - Upgrade managed dependency: plexus-xml to 4.0.3
* [MRESOLVER-478] - Redisson named locks: upgrade to
org.redisson:redisson 3.26.0
* [MRESOLVER-479] - Hazelcast named locks: upgrade to
com.hazelcast:hazelcast 5.3.6

Have fun,
Maven Team

Re: Browsing Maven central buggy?

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

Sorry, I need to apologize, as the info I stated below is WRONG:
MIMA CLI uses Maven Indexer (Search API from
https://github.com/apache/maven-indexer) and it is Maven Indexer project
that is Java 11 since 7.x.

Sorry again,
T

On Wed, Jan 24, 2024 at 7:19 PM Tamás Cservenák  wrote:

> MIMA as a library is Java 8, but CLI is Java11+ (picocli)
>

Re: Browsing Maven central buggy?

MIMA as a library is Java 8, but CLI is Java11+ (picocli)

Thanks
T

On Wed, Jan 24, 2024 at 7:18 PM Greg Chabala  wrote:

> Repository readme says runtime is Java 8+, but:
>
> $ jbang mima@maveniverse
> Error: A JNI error has occurred, please check your installation and try
> again
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> eu/maveniverse/maven/mima/cli/Main has been compiled by a more recent
> version of the Java Runtime (class file version 55.0), this version of the
> Java Runtime only recognizes class file versions up to 52.0
>
> On Wed, Jan 24, 2024 at 12:10 PM Tamás Cservenák 
> wrote:
>
> > Basically, all you need is JBang installed, and then
> >
> > $ jbang mima@maveniverse
> >
> > will figure out what it is, download and launch the CLI for you. In CLI
> use
> > `help` to get around.
> >
> > Without Jbang you need to download latest CLI uberJAR that is here:
> >
> >
> https://repo.maven.apache.org/maven2/eu/maveniverse/maven/mima/cli/2.4.6/cli-2.4.6-uber.jar
> >
> > And then just
> > $ java -jar cli-2.4.6-uber.jar
> >
> > And same thing as above with JBang...
> >
> > Thanks
> > T
> >
> > On Wed, Jan 24, 2024 at 6:36 PM Manfred Moser 
> > wrote:
> >
> > > Well.. you cant really just show this video without pointing to more
> > > help. So to get started ...
> > >
> > > https://github.com/maveniverse/mima
> > >
> > > used with
> > >
> > > https://www.jbang.dev/
> > >
> > > Any other tips Tamas?
> > >
> > > Manfred
> > >
> > >
> > > On 2024-01-24 09:22, Tamás Cservenák wrote:
> > > > Or something like this:
> > > > https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm
> > > >
> > > > ;)
> > > >
> > > > T
> > > >
> > > > On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser <
> manf...@simpligility.ca
> > >
> > > > wrote:
> > > >
> > > >> I suggest to use the maintained search and browse frontend from
> > Sonatype
> > > >> instead.
> > > >>
> > > >> https://search.maven.org/ .. same as https://central.sonatype.com/
> > > >>
> > > >> And browse at https://central.sonatype.com/search
> > > >>
> > > >> It sits on top of the same data and is very nice indeed .. props to
> > > >> Brian Fox and team btw!
> > > >>
> > > >> Manfred
> > > >>
> > > >> On 2024-01-24 08:57, Tamás Cservenák wrote:
> > > >>> Howdy,
> > > >>>
> > > >>> Yes, this is a known problem, but it does not affect Maven, as it
> > does
> > > >> not
> > > >>> "browse".
> > > >>> Basically you have to go directly to the directory you are looking
> > for,
> > > >> and
> > > >>> not rely on HTML "index page" as that seems not maintained since a
> > > while.
> > > >>>
> > > >>> T
> > > >>>
> > > >>> On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit  >
> > > >> wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> browsing Maven Central using a webbrowser seems, well, a bit
> buggy:
> > > >>>>
> > > >>>> In
> > https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
> > > >>>> for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
> > > >>>> whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not
> > > visible.
> > > >>>>
> > > >>>> The same happens for a few other GAV coordinates such as
> > > >>>>
> https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/
> > > or
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
> > > >>>> :
> > > >>>> The directories exist, but one level above these versions are not
> > > shown.
> > > >>>>
> > > >>>> Is this a known problem?
> > > >>>>
> > > >>>>
> > > >>>> Thorsten
> > > >>>>
> > > >>>>
> > -
> > > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > >>>> For additional commands, e-mail: users-h...@maven.apache.org
> > > >>>>
> > > >>>>
> > > >>
> -
> > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > >> For additional commands, e-mail: users-h...@maven.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Browsing Maven central buggy?

Basically, all you need is JBang installed, and then

$ jbang mima@maveniverse

will figure out what it is, download and launch the CLI for you. In CLI use
`help` to get around.

Without Jbang you need to download latest CLI uberJAR that is here:
https://repo.maven.apache.org/maven2/eu/maveniverse/maven/mima/cli/2.4.6/cli-2.4.6-uber.jar

And then just
$ java -jar cli-2.4.6-uber.jar

And same thing as above with JBang...

Thanks
T

On Wed, Jan 24, 2024 at 6:36 PM Manfred Moser 
wrote:

> Well.. you cant really just show this video without pointing to more
> help. So to get started ...
>
> https://github.com/maveniverse/mima
>
> used with
>
> https://www.jbang.dev/
>
> Any other tips Tamas?
>
> Manfred
>
>
> On 2024-01-24 09:22, Tamás Cservenák wrote:
> > Or something like this:
> > https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm
> >
> > ;)
> >
> > T
> >
> > On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser 
> > wrote:
> >
> >> I suggest to use the maintained search and browse frontend from Sonatype
> >> instead.
> >>
> >> https://search.maven.org/ .. same as https://central.sonatype.com/
> >>
> >> And browse at https://central.sonatype.com/search
> >>
> >> It sits on top of the same data and is very nice indeed .. props to
> >> Brian Fox and team btw!
> >>
> >> Manfred
> >>
> >> On 2024-01-24 08:57, Tamás Cservenák wrote:
> >>> Howdy,
> >>>
> >>> Yes, this is a known problem, but it does not affect Maven, as it does
> >> not
> >>> "browse".
> >>> Basically you have to go directly to the directory you are looking for,
> >> and
> >>> not rely on HTML "index page" as that seems not maintained since a
> while.
> >>>
> >>> T
> >>>
> >>> On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit 
> >> wrote:
> >>>> Hi,
> >>>>
> >>>> browsing Maven Central using a webbrowser seems, well, a bit buggy:
> >>>>
> >>>> In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
> >>>> for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
> >>>> whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not
> visible.
> >>>>
> >>>> The same happens for a few other GAV coordinates such as
> >>>> https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/
> or
> >>>>
> >>>>
> >>
> https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
> >>>> :
> >>>> The directories exist, but one level above these versions are not
> shown.
> >>>>
> >>>> Is this a known problem?
> >>>>
> >>>>
> >>>> Thorsten
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>>
> >>>>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Browsing Maven central buggy?

Or something like this:
https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm

;)

T

On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser 
wrote:

> I suggest to use the maintained search and browse frontend from Sonatype
> instead.
>
> https://search.maven.org/ .. same as https://central.sonatype.com/
>
> And browse at https://central.sonatype.com/search
>
> It sits on top of the same data and is very nice indeed .. props to
> Brian Fox and team btw!
>
> Manfred
>
> On 2024-01-24 08:57, Tamás Cservenák wrote:
> > Howdy,
> >
> > Yes, this is a known problem, but it does not affect Maven, as it does
> not
> > "browse".
> > Basically you have to go directly to the directory you are looking for,
> and
> > not rely on HTML "index page" as that seems not maintained since a while.
> >
> > T
> >
> > On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit 
> wrote:
> >
> >> Hi,
> >>
> >> browsing Maven Central using a webbrowser seems, well, a bit buggy:
> >>
> >> In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
> >> for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
> >> whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible.
> >>
> >> The same happens for a few other GAV coordinates such as
> >> https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or
> >>
> >>
> https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
> >> :
> >> The directories exist, but one level above these versions are not shown.
> >>
> >> Is this a known problem?
> >>
> >>
> >> Thorsten
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Browsing Maven central buggy?

Howdy,

Yes, this is a known problem, but it does not affect Maven, as it does not
"browse".
Basically you have to go directly to the directory you are looking for, and
not rely on HTML "index page" as that seems not maintained since a while.

T

On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit  wrote:

> Hi,
>
> browsing Maven Central using a webbrowser seems, well, a bit buggy:
>
> In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
> for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
> whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible.
>
> The same happens for a few other GAV coordinates such as
> https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or
>
> https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
> :
> The directories exist, but one level above these versions are not shown.
>
> Is this a known problem?
>
>
> Thorsten
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

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

Howdy,

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

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

This is a fifth *PREVIEW* (alpha-4 was scrubbed) release of upcoming Maven
Resolver 2.0.0 meant for users of Resolver to pick it up and adapt code if
needed. This alpha contains almost all of the planned features and
improvements, and for sure some unplanned bugs as well.

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

** Improvement
* [MRESOLVER-460] - More filter improvements for H/L
** Task
* [MRESOLVER-457] - Revert MRESOLVER-446
* [MRESOLVER-459] - Make default repository system session usable in
tests
* [MRESOLVER-461] - DependencyManager cleanup
* [MRESOLVER-462] - Introduce transitive classic depMgr as well
** Dependency upgrade
* [MRESOLVER-458] - Update to Maven 4.0.0-alpha-10

Have fun,
Maven Team

[ANN] Apache Maven Indexer 7.1.2 released

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

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

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

Release Notes - Maven Indexer - Version 7.1.2

** Bug
* [MINDEXER-214] - ArtifactContext should not log warnings if artifact
is not zip file
** Dependency upgrade
* [MINDEXER-212] - Update jsoup to 1.17.2
* [MINDEXER-213] - Update Lucene to 9.9.1

Have fun,
-The Apache Maven team

Re: Unexpected behavior of the javadoc plugin?

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

Hej Ceki,

Nils is right, all the elements of BOM are ignored but the depMgt.
So what you "pollute" are those extra handfuls of bytes that consumers
download, only to toss them away.
So this is not a problem IMHO.

Thanks
T


On Tue, Jan 9, 2024 at 12:34 AM Nils Breunese  wrote:

>  or  elements are not imported when a project imports a BOM
> with import, only  is imported.
>
> Other elements only get inherited when a project uses another project as a
> parent.
>
> > Op 8 jan 2024, om 20:57 heeft Ceki Gulcu  het
> volgende geschreven:
> >
> > Hi Tamás,
> >
> > Thank you for your comments.
> >
> > My question is more regarding the need to place a javadoc 
> > element in the BOM file, i.e top level pom.xml, instead of
> parent/pom.xml.
> >
> > Once the javadoc related  element is in the BOM file, it works
> fine.
> >
> > However, given the BOM file is intended to be imported, I would prefer
> > to keep it minimal and have it free of any  and  elements
> > in order to not pollute importing projects.
> >
> > Is my concern warranted?
> >
> > --
> > Ceki Gülcü
> >
> > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> >
> > On 12/28/2023 7:17 PM, Tamás Cservenák wrote:
> >> Hej Ceki,
> >>
> >> I also experience javadoc misbehaviour when JPMS/jigsaw is involved,
> and _I
> >> think_ it boils down when it tries to be "smart" when it comes to
> JPMS...
> >> See master of maven-resolver, as it was suffering with similar issues,
> and
> >> this change:
> >>
> https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae
> >> (that was a few releases ago, things may have changed around).
> >>
> >> Try out this flag if you are on fairly new version:
> >>
> https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode
> >>
> >> HTH
> >> Tamas
> >>
> >> On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu  wrote:
> >>
> >>>
> >>> Hello all,
> >>>
> >>> Given the javadoc generation is an important part of software projects,
> >>> maybe someone would care to comment whether the behavior described
> below
> >>> is expected or not?
> >>>
> >>> In the meantime, happy new year to all,
> >>>
> >>> --
> >>> Ceki Gülcü
> >>>
> >>> Sponsoring SLF4J/logback/reload4j at
> https://github.com/sponsors/qos-ch
> >>>
> >>> On 12/23/2023 9:34 PM, Ceki Gulcu wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> I would like to share what looks to me like an unexpected behavior of
> >>>> the javadoc plugin, more specifically when run as javadoc:aggregate.
> >>>>
> >>>>
> >>>> The SLF4J project uses the "Refining the BOM Pattern" variant as
> >>>> explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
> >>>> specifically, the top level pom.xml is the BOM and project modules
> >>>> import ../parent/pom.xml.
> >>>>
> >>>> Source code is available at [2].
> >>>>
> >>>> Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized
> >>> project.
> >>>>
> >>>> When trying to create aggregated javadocs with the javadoc:aggreate
> >>>> command, the javadoc generation would fail with javadoc complaining
> >>>> about unnamed modules and other miscellaneous problems. The solution
> was
> >>>> to skip certain modules for which there was no need to generate
> javadocs
> >>>> to begin with.
> >>>>
> >>>> Surprisingly, adding  in parent/pom.xml of the
> >>>> javdoc-plugin configuration would have no effect. However, specifying
> >>>> -Dmaven.javadoc.skippedModules would work as expected.
> >>>>
> >>>> The advice commonly found on various forum about the placement of the
> >>>> javadoc plugin configuration pertain to  and/or 
> >>>> section. In my case, this advice looks irrelevant (see below).
> >>>>
> >>>> After a lot of head scratching, placing the javadoc-plugin
> configuration
> >>>> in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
> >>>> configuration have the desired effect. This is quite surprising as the
>

Re: Unexpected behavior of the javadoc plugin?

2023-12-28 Thread Tamás Cservenák

Hej Ceki,

I also experience javadoc misbehaviour when JPMS/jigsaw is involved, and _I
think_ it boils down when it tries to be "smart" when it comes to JPMS...
See master of maven-resolver, as it was suffering with similar issues, and
this change:
https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae
(that was a few releases ago, things may have changed around).

Try out this flag if you are on fairly new version:
https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode

HTH
Tamas

On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu  wrote:

>
> Hello all,
>
> Given the javadoc generation is an important part of software projects,
> maybe someone would care to comment whether the behavior described below
> is expected or not?
>
> In the meantime, happy new year to all,
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
>
> On 12/23/2023 9:34 PM, Ceki Gulcu wrote:
> >
> > Hello,
> >
> > I would like to share what looks to me like an unexpected behavior of
> > the javadoc plugin, more specifically when run as javadoc:aggregate.
> >
> >
> > The SLF4J project uses the "Refining the BOM Pattern" variant as
> > explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
> > specifically, the top level pom.xml is the BOM and project modules
> > import ../parent/pom.xml.
> >
> > Source code is available at [2].
> >
> > Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized
> project.
> >
> > When trying to create aggregated javadocs with the javadoc:aggreate
> > command, the javadoc generation would fail with javadoc complaining
> > about unnamed modules and other miscellaneous problems. The solution was
> > to skip certain modules for which there was no need to generate javadocs
> > to begin with.
> >
> > Surprisingly, adding  in parent/pom.xml of the
> > javdoc-plugin configuration would have no effect. However, specifying
> > -Dmaven.javadoc.skippedModules would work as expected.
> >
> > The advice commonly found on various forum about the placement of the
> > javadoc plugin configuration pertain to  and/or 
> > section. In my case, this advice looks irrelevant (see below).
> >
> > After a lot of head scratching, placing the javadoc-plugin configuration
> > in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
> > configuration have the desired effect. This is quite surprising as the
> > configuration of other plugins have an effect when placed in
> parent/pom.xml.
> >
> > To reproduce this behavior, you can check out the code of the SLF4J
> > project from [2] and run "mvn javadoc:aggregate". (To observe a failure
> > the javadoc-plugin configuration needs to commented out in top-level
> > pom.xml and uncommented in parent/pom.xml before running "mvn
> > javadoc:aggregate".)
> >
> > I am wondering whether the behavior of javadoc:aggregate described above
> > is expected or actually a problem?
> >
> > Best regards,
> >
> > [1]
> https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern
> > [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 4.0 release timeline

2023-12-21 Thread Tamás Cservenák

Well,

we have some notes and scratches around like these:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack

But these are about Maven "ecosystem" that needed a lot of work to make
those up to date.
The "battle" with Maven4 API is _not present here_, as we can only work by
data that "trickles" to us,
or we spend our own energy to look up all the plugins out there...

Thanks
T

On Wed, Dec 20, 2023 at 12:55 PM Debraj Manna 
wrote:

> When I asked about the release timeline, I was enquiring whether Maven also
> has release management documentation like the way some other apache
> projects Flink or Kafka do. I was not able to find it for maven 4.
>
> Anyways thanks, Marteen for the references.
>
> https://cwiki.apache.org/confluence/display/FLINK/2.0+Release
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>
> On Tue, Dec 19, 2023 at 9:53 PM 
> wrote:
>
> > Thank you!  I'd seen [4] but not sure if I've seen [2]
> >
> > -Original Message-
> > From: Maarten Mulders 
> > Sent: Tuesday, December 19, 2023 9:07 AM
> > To: users@maven.apache.org
> > Subject: Re: Maven 4.0 release timeline
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > mthmuld...@apache.org Do not click on links, open attachments, or
> respond
> > unless you recognize the sender and can validate the content is safe.
> > On 18/12/2023 21:38, mark.yagnatin...@barclays.com.INVALID wrote:
> > > I'm not the original asker but this kind of answer tends to annoy me.
> > > Yes, there is no "official" release timeline, you're obviously not
> going
> > to promise anything, all this is (hopefully?) clear, BUT!
> > > You no doubt have GUESSES.  And your guesses are no doubt better than
> > that of most uninformed outsiders.
> > > As an outsider, I have no idea what the "status" of maven 4 is, and I
> > can't even begin to guess how I would find out.
> > > Should I try to catch up on the last few years of traffic on the
> > developer email lists?
> > > Or perhaps the answer can be divined from the issue tracker?  If so,
> how?
> > > Is it expected that alpha-10 will be the last alpha, and the next build
> > will be a beta?
> > > If that is NOT what you expect, then what's the primary hold up?
> > > Are there major features that have yet to be implemented?
> > > Or perhaps the features are mostly done but they're still a bit buggy?
> > > Or perhaps the code quality is pretty solid and you just want to
> reserve
> > the right to make backwards incompatible changes, and there's a policy to
> > not do that after hitting beta?
> > >
> > > You get the idea.  As an insider, you probably think to yourself
> > "there's no telling when we'll be done; it depends on a zillion
> > unpredictable things".
> > > But as outsiders, we don't even know whether the ETA is a few months or
> > a few years or a few decades or perhaps just a few weeks.
> > >
> > > Sorry if that came off as a bit of a rant :)
> > The good news is, you don't have to read the mailing list history, nor
> > dive into the issue tracker, nor read the git history. If you're curious
> > what Maven 4 will bring, I can highly recommend watching Karl-Heinz'
> > talk [1]. Don't feel like watching somebody talk? You can read about some
> > interesting articles and documentation: [2], [3], [4].
> >
> > Hope this helps,
> >
> >
> > Maarten
> >
> >
> > [1]
> >
> https://clicktime.symantec.com/15sMvS6QDE6q6Jf47vc58?h=tZSjeMLRMnL1sHS93b7vt02NnPNvJwK6-ee8iyLMi5Q==https://youtu.be/fHeVMbQNbgQ
> > [2]
> >
> https://clicktime.symantec.com/15sMFnY8YJe5nk3fmTQtA?h=sQem5P67RYOhsiW9Hm_YeD-PIfsaReOsBbMYvlLdgRk==https://maven.apache.org/guides/mini/guide-multiple-modules-4.html
> > [3]
> >
> https://clicktime.symantec.com/15sM1HxHATbJYuZu8nDSJ?h=s87AfscrtMWpDN9FZxBHl_MjXK1i_ohGn2TWRZhFFZ4==https://cwiki.apache.org/confluence/display/MAVEN/Build%2Bvs%2BConsumer%2BPOM
> > [4]
> >
> https://clicktime.symantec.com/15sMqbu7kcREgMq8aNCvW?h=2OV2Xb8OY1yozkosb4XLJzGzmH5eCx0rkkaq0thqbr4==https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
> >
> > PS. Most of the above was exactly one Google search away...: "Maven 4"
> >
> > > -Original Message-
> > > From: Karl Heinz Marbaise 
> > > Sent: Monday, December 18, 2023 3:18 PM
> > > To: Maven Users List ; Debraj Manna
> > > 
> > > Subject: Re: Maven 4.0 release timeline
> > >
> > >
> > > CAUTION: This email originated from outside our organisation -
> > khmarba...@gmx.de.INVALID Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content is
> > safe.
> > > On 18.12.23 06:27, Debraj Manna wrote:
> > >> Can someone let me know when Maven 4 is expected to be released?
> > >> Where can I view its release timelines?
> > >>
> > >
> > > We are an open source project. We don't have a release timeline.
> > >
> > > Maven 4.0.0 will be there when it's there.
> > >
> > >
>

Re: Maven 4.0 release timeline

Well, IDE integrations are completely different stuff... What IDE do you
use?
Can I recommend you to try it out in Terminal instead?

T

On Mon, Dec 18, 2023 at 11:18 PM 
wrote:

> Thanks!  Just tried in my IDE and it failed, but not sure if that's an
> issue with maven or with IDE.
> (I have a multi-module project and it tried to download the submodules
> instead of using the local source code)
>
> -Original Message-----
> From: Tamás Cservenák 
> Sent: Monday, December 18, 2023 5:08 PM
> To: Maven Users List 
> Cc: subharaj.ma...@gmail.com
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation -
> ta...@cservenak.net Do not click on links, open attachments, or respond
> unless you recognize the sender and can validate the content is safe.
> Howdy,
>
> And to reply to the "longer stuff":
>
> Current Maven 4 (on vote, so 3 days if vote passes OK and files land on
> Central) is alpha-10.
>
> As with any previous alphas, the _minimal_ requirement is that UT passes,
> Maven can build itself, and that to pass Maven IT suite. IT suite is
> currently, in this very moment 909 IT tests, but they grow constantly, as
> new bugs or new features are added, this link
> https://clicktime.symantec.com/15sM1Hx4Zk69FcT4Re31T?h=WCNYF5iZoo32qX5Hxyc8Qrzhc1t-HKpREAcWNL1r7t8==https://github.com/apache/maven-integration-testing/pulse/monthly
> shows there were 3 ITs added last, two bugs from alpha-9 and new feature
> regarding plugin validation.
>
> As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled:
>
> https://clicktime.symantec.com/15sMAxLdUyTL5W6uWkqJh?h=KbxkwIqLoMQYfHx5OCZ4V-Mu7NdrW7MXjqNgyyl25so==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MNG%2520AND%2520fixVersion%2520%253D%25204.0.0-alpha-11
>
> Currently we work on stabilizing resolver and maven (both are alphas!),
> and ironing out the new Maven 4 API (thus converting MANY core plugins to
> use new API), see here:
> https://clicktime.symantec.com/15sM689M2MmjfZGyyCSA5?h=7_-nR2qTzP6RIZLBqH9pHMeQfYQjGw5njIatpLSW6_U==https://github.com/apache/maven/pull/1048
>
> Basically we make sure that the new API delivers _everything_ we need in
> core plugins, and even more, as some information trickles from third party
> plugins as well. We have to do this "intelligence" work in alpha, where we
> can break APIs, as we really need to adjust, adapt and make sure all this
> once is set in stone (released as final), will work out for everyone doing
> plugin development.
>
> Good news is that Resolver 2.0.0 is pretty much "done":
>
> https://clicktime.symantec.com/15sMFnXuwb8vVSvq4KETK?h=djE-5RAYZwC_J0iiRHe3cw4LXST_S1deoAEfdJrJlfU==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MRESOLVER%2520AND%2520fixVersion%2520%253D%25202.0.0-alpha-6
>
> I am not saying "resolver is done-done", just that we are "over the hill",
> as regarding issue numbers over there. Most probably will have some lurking
> bugs, like the last one was in Resolver 2 alpha-3 (plagues Maven 4 alpha-9)
> about new "jdk" transport. And for sure will have bugs regarding new
> transport features, as they are not ironed out fully.
>
> Maven core is completely different, especially due to its API. Hence, the
> more (intel) we get the merrier, as we see "core plugins" only.
>
> So please try out, test it and report back.
>
> Thanks
> T
>
> On Mon, Dec 18, 2023 at 9:39 PM 
> wrote:
>
> > I'm not the original asker but this kind of answer tends to annoy me.
> > Yes, there is no "official" release timeline, you're obviously not
> > going to promise anything, all this is (hopefully?) clear, BUT!
> > You no doubt have GUESSES.  And your guesses are no doubt better than
> > that of most uninformed outsiders.
> > As an outsider, I have no idea what the "status" of maven 4 is, and I
> > can't even begin to guess how I would find out.
> > Should I try to catch up on the last few years of traffic on the
> > developer email lists?
> > Or perhaps the answer can be divined from the issue tracker?  If so, how?
> > Is it expected that alpha-10 will be the last alpha, and the next
> > build will be a beta?
> > If that is NOT what you expect, then what's the primary hold up?
> > Are there major features that have yet to be implemented?
> > Or perhaps the features are mostly done but they're still a bit buggy?
> > Or perhaps the code quality is pretty solid and you just want to
> > reserve the right to make backwards incompatible changes, and there's
> > a policy to not do that after hitting beta?
> >
> > You g

Re: Maven 4.0 release timeline

Howdy,

And to reply to the "longer stuff":

Current Maven 4 (on vote, so 3 days if vote passes OK and files land on
Central) is alpha-10.

As with any previous alphas, the _minimal_ requirement is that UT passes,
Maven can build itself, and that to pass Maven IT suite. IT suite is
currently, in this very moment 909 IT tests, but they grow constantly, as
new bugs or new features are added, this link
https://github.com/apache/maven-integration-testing/pulse/monthly shows
there were 3 ITs added last, two bugs from alpha-9 and new feature
regarding plugin validation.

As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-alpha-11

Currently we work on stabilizing resolver and maven (both are alphas!), and
ironing out the new Maven 4 API (thus converting MANY core plugins to use
new API), see here: https://github.com/apache/maven/pull/1048

Basically we make sure that the new API delivers _everything_ we need in
core plugins, and even more, as some information trickles from third party
plugins as well. We have to do this "intelligence" work in alpha, where we
can break APIs, as we really need to adjust, adapt and make sure all this
once is set in stone (released as final), will work out for everyone doing
plugin development.

Good news is that Resolver 2.0.0 is pretty much "done":
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-6

I am not saying "resolver is done-done", just that we are "over the hill",
as regarding issue numbers over there. Most probably will have some lurking
bugs, like the last one was in Resolver 2 alpha-3 (plagues Maven 4 alpha-9)
about new "jdk" transport. And for sure will have bugs regarding new
transport features, as they are not ironed out fully.

Maven core is completely different, especially due to its API. Hence, the
more (intel) we get the merrier, as we see "core plugins" only.

So please try out, test it and report back.

Thanks
T

On Mon, Dec 18, 2023 at 9:39 PM 
wrote:

> I'm not the original asker but this kind of answer tends to annoy me.
> Yes, there is no "official" release timeline, you're obviously not going
> to promise anything, all this is (hopefully?) clear, BUT!
> You no doubt have GUESSES.  And your guesses are no doubt better than that
> of most uninformed outsiders.
> As an outsider, I have no idea what the "status" of maven 4 is, and I
> can't even begin to guess how I would find out.
> Should I try to catch up on the last few years of traffic on the developer
> email lists?
> Or perhaps the answer can be divined from the issue tracker?  If so, how?
> Is it expected that alpha-10 will be the last alpha, and the next build
> will be a beta?
> If that is NOT what you expect, then what's the primary hold up?
> Are there major features that have yet to be implemented?
> Or perhaps the features are mostly done but they're still a bit buggy?
> Or perhaps the code quality is pretty solid and you just want to reserve
> the right to make backwards incompatible changes, and there's a policy to
> not do that after hitting beta?
>
> You get the idea.  As an insider, you probably think to yourself "there's
> no telling when we'll be done; it depends on a zillion unpredictable
> things".
> But as outsiders, we don't even know whether the ETA is a few months or a
> few years or a few decades or perhaps just a few weeks.
>
> Sorry if that came off as a bit of a rant :)
>
>
> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Monday, December 18, 2023 3:18 PM
> To: Maven Users List ; Debraj Manna <
> subharaj.ma...@gmail.com>
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation -
> khmarba...@gmx.de.INVALID Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> On 18.12.23 06:27, Debraj Manna wrote:
> > Can someone let me know when Maven 4 is expected to be released? Where
> > can I view its release timelines?
> >
>
> We are an open source project. We don't have a release timeline.
>
> Maven 4.0.0 will be there when it's there.
>
>
> If you want to help testing, there is 4.0.0-alpha-9 version available (at
> the moment the VOTE for 4.0.0-alpha-10 is running developers list)..
>
>
>
> https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1ZxyuIqUZPLWnHHC2LmzcP6V9UINAuTSc==https://maven.apache.org/download.cgi
>
> https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjOAtqB_jneksRphxbi0aG911AdXT1E==https://maven.apache.org/docs/history.html
>
> https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zykQUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://maven.apache.org/mailing-lists.html
>
> Kind regards
> Karl Heinz Marbaise
> Apache Maven PMC Chairman
>
>
> -
> To unsubscribe,

Re: Maven 4.0 release timeline

Yup.

If the vote passes OK, these files will land in central as well.

T

On Mon, Dec 18, 2023 at 9:59 PM 
wrote:

> Ah, much better!  I guess I can ignore the cyclondex files and grab a
> plain old zip?
>
> -Original Message-----
> From: Tamás Cservenák 
> Sent: Monday, December 18, 2023 3:49 PM
> To: Maven Users List 
> Cc: subharaj.ma...@gmail.com
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation -
> ta...@cservenak.net Do not click on links, open attachments, or respond
> unless you recognize the sender and can validate the content is safe.
> I really recommend alpha10, distros are here
> https://clicktime.symantec.com/15t6V3WB3Q9UkWhf5JPD6?h=DNfkwbsM2Nbwr9Re8FSzo--npL69CABPYMYoaHsSC-A==https://repository.apache.org/content/repositories/maven-2050/org/apache/maven/apache-maven/4.0.0-alpha-10/
>
> Thanks
> T
>
> On Mon, Dec 18, 2023, 21:48  wrote:
>
> > Navigating that directory tree seems a bit intimidating... can I try
> > alpha-8 or better wait for alpha-10 to officially come out?
> >
> > -Original Message-
> > From: Tamás Cservenák 
> > Sent: Monday, December 18, 2023 3:43 PM
> > To: Maven Users List 
> > Cc: subharaj.ma...@gmail.com
> > Subject: Re: Maven 4.0 release timeline
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > ta...@cservenak.net Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content is
> safe.
> > ...or,.just go to staging repo
> >
> > https://clicktime.symantec.com/15siaWLYGbnA1MrGqWQwt?h=qkVv-eG-rGmVca6
> > UeWqg9iHAifq1sVHsvsDmSfLKZ2o==https://clicktime.symantec.com/15t6QDJ
> > tanTtLZsjXjz4U?h=4Jzcps2egc7Hk1dplHDiulcv9nRA0wSTiAQlv1W8Bro==https:
> > //repository.apache.org/content/repositories/maven-2050
> > download the distro and try on some of your projects?
> >
> > In case of problems be so kind to report the issues so we can iron
> > them out.
> >
> > Imho, alpha 10 is in very good shape. Alpha-9 had a nasty bug and
> > could remain running the process. Do not use it.
> >
> > Thanks
> > T
> >
> > On Mon, Dec 18, 2023, 21:39 
> wrote:
> >
> > > I'm not the original asker but this kind of answer tends to annoy me.
> > > Yes, there is no "official" release timeline, you're obviously not
> > > going to promise anything, all this is (hopefully?) clear, BUT!
> > > You no doubt have GUESSES.  And your guesses are no doubt better
> > > than that of most uninformed outsiders.
> > > As an outsider, I have no idea what the "status" of maven 4 is, and
> > > I can't even begin to guess how I would find out.
> > > Should I try to catch up on the last few years of traffic on the
> > > developer email lists?
> > > Or perhaps the answer can be divined from the issue tracker?  If so,
> how?
> > > Is it expected that alpha-10 will be the last alpha, and the next
> > > build will be a beta?
> > > If that is NOT what you expect, then what's the primary hold up?
> > > Are there major features that have yet to be implemented?
> > > Or perhaps the features are mostly done but they're still a bit buggy?
> > > Or perhaps the code quality is pretty solid and you just want to
> > > reserve the right to make backwards incompatible changes, and
> > > there's a policy to not do that after hitting beta?
> > >
> > > You get the idea.  As an insider, you probably think to yourself
> > > "there's no telling when we'll be done; it depends on a zillion
> > > unpredictable things".
> > > But as outsiders, we don't even know whether the ETA is a few months
> > > or a few years or a few decades or perhaps just a few weeks.
> > >
> > > Sorry if that came off as a bit of a rant :)
> > >
> > >
> > > -Original Message-
> > > From: Karl Heinz Marbaise 
> > > Sent: Monday, December 18, 2023 3:18 PM
> > > To: Maven Users List ; Debraj Manna <
> > > subharaj.ma...@gmail.com>
> > > Subject: Re: Maven 4.0 release timeline
> > >
> > >
> > > CAUTION: This email originated from outside our organisation -
> > > khmarba...@gmx.de.INVALID Do not click on links, open attachments,
> > > or respond unless you recognize the sender and can validate the
> > > content is safe.
> > > On 18.12.23 06:27, Debraj Manna wrote:
> > > > Can someone let me know when Maven 4 is expected to be re

Re: Maven 4.0 release timeline

I really recommend alpha10, distros are here
https://repository.apache.org/content/repositories/maven-2050/org/apache/maven/apache-maven/4.0.0-alpha-10/

Thanks
T

On Mon, Dec 18, 2023, 21:48  wrote:

> Navigating that directory tree seems a bit intimidating... can I try
> alpha-8 or better wait for alpha-10 to officially come out?
>
> -Original Message-----
> From: Tamás Cservenák 
> Sent: Monday, December 18, 2023 3:43 PM
> To: Maven Users List 
> Cc: subharaj.ma...@gmail.com
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation -
> ta...@cservenak.net Do not click on links, open attachments, or respond
> unless you recognize the sender and can validate the content is safe.
> ...or,.just go to staging repo
>
> https://clicktime.symantec.com/15siaWLYGbnA1MrGqWQwt?h=qkVv-eG-rGmVca6UeWqg9iHAifq1sVHsvsDmSfLKZ2o==https://repository.apache.org/content/repositories/maven-2050
> download the distro and try on some of your projects?
>
> In case of problems be so kind to report the issues so we can iron them
> out.
>
> Imho, alpha 10 is in very good shape. Alpha-9 had a nasty bug and could
> remain running the process. Do not use it.
>
> Thanks
> T
>
> On Mon, Dec 18, 2023, 21:39  wrote:
>
> > I'm not the original asker but this kind of answer tends to annoy me.
> > Yes, there is no "official" release timeline, you're obviously not
> > going to promise anything, all this is (hopefully?) clear, BUT!
> > You no doubt have GUESSES.  And your guesses are no doubt better than
> > that of most uninformed outsiders.
> > As an outsider, I have no idea what the "status" of maven 4 is, and I
> > can't even begin to guess how I would find out.
> > Should I try to catch up on the last few years of traffic on the
> > developer email lists?
> > Or perhaps the answer can be divined from the issue tracker?  If so, how?
> > Is it expected that alpha-10 will be the last alpha, and the next
> > build will be a beta?
> > If that is NOT what you expect, then what's the primary hold up?
> > Are there major features that have yet to be implemented?
> > Or perhaps the features are mostly done but they're still a bit buggy?
> > Or perhaps the code quality is pretty solid and you just want to
> > reserve the right to make backwards incompatible changes, and there's
> > a policy to not do that after hitting beta?
> >
> > You get the idea.  As an insider, you probably think to yourself
> > "there's no telling when we'll be done; it depends on a zillion
> > unpredictable things".
> > But as outsiders, we don't even know whether the ETA is a few months
> > or a few years or a few decades or perhaps just a few weeks.
> >
> > Sorry if that came off as a bit of a rant :)
> >
> >
> > -Original Message-
> > From: Karl Heinz Marbaise 
> > Sent: Monday, December 18, 2023 3:18 PM
> > To: Maven Users List ; Debraj Manna <
> > subharaj.ma...@gmail.com>
> > Subject: Re: Maven 4.0 release timeline
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > khmarba...@gmx.de.INVALID Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > On 18.12.23 06:27, Debraj Manna wrote:
> > > Can someone let me know when Maven 4 is expected to be released?
> > > Where can I view its release timelines?
> > >
> >
> > We are an open source project. We don't have a release timeline.
> >
> > Maven 4.0.0 will be there when it's there.
> >
> >
> > If you want to help testing, there is 4.0.0-alpha-9 version available
> > (at the moment the VOTE for 4.0.0-alpha-10 is running developers list)..
> >
> >
> >
> > https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1Zxyu
> > IqUZPLWnHHC2LmzcP6V9UINAuTSc==https://clicktime.symantec.com/15siQqw
> > yMNQyBUCRkPcee?h=-wnFgkT4h16bjz0t2Vuc_NutxQbPp0L_p6KY3P3WB2E==https:
> > //maven.apache.org/download.cgi
> >
> > https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjO
> > AtqB_jneksRphxbi0aG911AdXT1E==https://clicktime.symantec.com/15siL1k
> > gtkjNmXNWCqDW2?h=BX1saw3vPZ85tRY4Qc9ZmbpOGkojF6vC2umq1TvP1eM==https:
> > //maven.apache.org/docs/history.html
> >
> > https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zyk
> > QUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://clicktime.symantec.com/15siVg9
> > Foz6ZbR2MHx1oG?h=C_JJFO_gli3dfK9BJoJ1t22_wu2YHA7V4ywpVxFiPlA==https:
> > //maven.apache.org/mailing-lists

Re: Maven 4.0 release timeline

...or,.just go to staging repo
https://repository.apache.org/content/repositories/maven-2050 download the
distro and try on some of your projects?

In case of problems be so kind to report the issues so we can iron them out.

Imho, alpha 10 is in very good shape. Alpha-9 had a nasty bug and could
remain running the process. Do not use it.

Thanks
T

On Mon, Dec 18, 2023, 21:39  wrote:

> I'm not the original asker but this kind of answer tends to annoy me.
> Yes, there is no "official" release timeline, you're obviously not going
> to promise anything, all this is (hopefully?) clear, BUT!
> You no doubt have GUESSES.  And your guesses are no doubt better than that
> of most uninformed outsiders.
> As an outsider, I have no idea what the "status" of maven 4 is, and I
> can't even begin to guess how I would find out.
> Should I try to catch up on the last few years of traffic on the developer
> email lists?
> Or perhaps the answer can be divined from the issue tracker?  If so, how?
> Is it expected that alpha-10 will be the last alpha, and the next build
> will be a beta?
> If that is NOT what you expect, then what's the primary hold up?
> Are there major features that have yet to be implemented?
> Or perhaps the features are mostly done but they're still a bit buggy?
> Or perhaps the code quality is pretty solid and you just want to reserve
> the right to make backwards incompatible changes, and there's a policy to
> not do that after hitting beta?
>
> You get the idea.  As an insider, you probably think to yourself "there's
> no telling when we'll be done; it depends on a zillion unpredictable
> things".
> But as outsiders, we don't even know whether the ETA is a few months or a
> few years or a few decades or perhaps just a few weeks.
>
> Sorry if that came off as a bit of a rant :)
>
>
> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Monday, December 18, 2023 3:18 PM
> To: Maven Users List ; Debraj Manna <
> subharaj.ma...@gmail.com>
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation -
> khmarba...@gmx.de.INVALID Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> On 18.12.23 06:27, Debraj Manna wrote:
> > Can someone let me know when Maven 4 is expected to be released? Where
> > can I view its release timelines?
> >
>
> We are an open source project. We don't have a release timeline.
>
> Maven 4.0.0 will be there when it's there.
>
>
> If you want to help testing, there is 4.0.0-alpha-9 version available (at
> the moment the VOTE for 4.0.0-alpha-10 is running developers list)..
>
>
>
> https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1ZxyuIqUZPLWnHHC2LmzcP6V9UINAuTSc==https://maven.apache.org/download.cgi
>
> https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjOAtqB_jneksRphxbi0aG911AdXT1E==https://maven.apache.org/docs/history.html
>
> https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zykQUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://maven.apache.org/mailing-lists.html
>
> Kind regards
> Karl Heinz Marbaise
> Apache Maven PMC Chairman
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> This message is for information purposes only. It is not a recommendation,
> advice, offer or solicitation to buy or sell a product or service, nor an
> official confirmation of any transaction. It is directed at persons who are
> professionals and is intended for the recipient(s) only. It is not directed
> at retail customers. This message is subject to the terms at:
> https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
> regarding marketing commentary from Barclays Sales and/or Trading desks,
> who are active market participants;
> https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Corporate and Investment Bank
> where we trade with you in principal-to-principal wholesale markets
> transactions; and in respect to Barclays Research, including disclosures
> relating to specific issuers, see: http://publicresearch.barclays.com.
> __
>
> If you are incorporated or operating in Australia, read these important
> disclosures:
> https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html
> .
>
> __
> For more details about how we use personal information, see our privacy
> notice: https://www.cib.barclays/disclosures/personal-information-use.html.
>
>
>

[ANN] Maven Resolver 2.0.0-alpha-5 released

2023-12-17 Thread Tamás Cservenák

Howdy,

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

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

This is a fourth *PREVIEW* (alpha-4 was scrubbed) release of upcoming Maven
Resolver 2.0.0 meant for users of Resolver to pick it up and adapt code if
needed.

Note: MRESOLVER-446 has been rolled back, client code should not depend on
the version scheme selector or version scheme scheme provider present in
alpha-5, as it is not to stay.

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

** Bug
* [MRESOLVER-455] - JDK transport: Improper handling of ofInputStream
body handlers in case of error
** New Feature
* [MRESOLVER-415] - New transport: JDK11 HTTP/2 capable
* [MRESOLVER-416] - New transport: Jetty, HTTP/2 capable
* [MRESOLVER-446] - Version Scheme Provider
* [MRESOLVER-451] - Expose version range processing strategies
** Improvement
* [MRESOLVER-335] - Better resolver errors for Artifact Not Found
* [MRESOLVER-445] - Simplify session handling, move out logic from
session builder
* [MRESOLVER-447] - Expose flatten method on RepositorySystem
* [MRESOLVER-450] - Add a RepositoryCache#computeIfAbsent method
** Task
* [MRESOLVER-443] - Integrate "configuration page generator" tool into
build/site
* [MRESOLVER-448] - Align Jetty versions
* [MRESOLVER-449] - Make HTTP transports use common test and server
* [MRESOLVER-454] - Update page "Upgrading Resolver"
** Dependency upgrade
* [MRESOLVER-452] - Update to Maven 4.0.0-alpha-9

Have fun,
Maven Team

[ANN] Maven Indexer 7.1.1 released

2023-12-16 Thread Tamás Cservenák

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

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

Release Notes - Maven Indexer - Version 7.1.1

** Bug
* [MINDEXER-207] - RR backend should handle 404 gracefully
** Task
* [MINDEXER-205] - Align Search API backend factories
* [MINDEXER-211] - Build cleanup
** Dependency upgrade
* [MINDEXER-208] - Apache Lucene 9.9.0 and other minor dependency bumps
* [MINDEXER-209] - Move off EOLd Jetty 9.x to 10.x
* [MINDEXER-210] - Upgrade Google Guava to 32.1.3-jre

Have fun,
-The Apache Maven team

Re: Configuring plugins by composition rather than inheritance

2023-12-05 Thread Tamás Cservenák

Howdy,

For importing plugins there was even some PoC like this:
https://github.com/apache/maven/pull/1190

Also, planned for maven4 to (or already is, Guillaume?) support mixins.

HTH
T

On Tue, Dec 5, 2023 at 12:51 PM Bernd Eckenfels 
wrote:

> Hello,
>
> I think that’s a long-standing restriction of mavens Pom-model, not sure
> it can easily be solved. Spring boot (and other frameworks) did not make
> the situation easier with their parent requirement (but then again there is
> not much alternatives).
>
> From my experience it seems a good idea to get away from a strict „simple
> company root“ requirement. (Due to release cycles it doesn’t do much for
> unifying build jobs anyway).
>
> Maven could improve with importing build/plugin sections like BOMs. I
> haven’t seen much talk about that in recent 4.0 discussions,
>
> Having said that a consumer Pom goes a good distance to make the parents
> less relevant. (Especially licensing/orga matters)
>
> Gruß
> Bernd
>
> Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00):
>
> > In my current project i'm working we already have a parent POM that I
> > should be inheriting from, but when trying to integrate the spring boot I
> > come into an issue that I should inherit their super pom instead of using
> > our own. For dependencies its pretty simple - you use the import scope,
> > but
> > what about plugins? I'm seeing some stackoverflow posts about the sameish
> > issue from 11 years ago that the suggestion was to use tiles plugin. Was
> > there any movement regarding this in the mean time?
> >
> > As a workaround I currently have a dedicated springboot runtime module
> > that
> > includes a single entry point with respective annotations to start the
> > application, and it directly inherits the spring boot super pom while
> > importing our dependencies via the depencendy management block but having
> > a
> > submodule not inherit a parent module feels weird
> >
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: what javac is actually used?

2023-12-04 Thread Tamás Cservenák

Howdy,

Did you figure out the effective configuration of m-compiler-p?
Or, do you maybe use the takari lifecycle? As it use Eclipse JDT by default
and totally disables/circumvents m-compiler-p...

Thanks
T

On Mon, Dec 4, 2023 at 9:09 AM Dave Dyer  wrote:

> Thanks, I'll follow up by trying to extract detailed info about
> what maven is actually doing.  Its not my build script; I'm just
> trying to figure out why the "better" Maven build is producing
> worse results than the Ant build it is supposed to replace.
>
> At 11:52 PM 12/3/2023, Bernd Eckenfels wrote:
> >Hallo,
> >
> >Dave Dyer wrote on 4. Dec 2023 08:27 (GMT +01:00):
> >
> >> It seems odd to me for maven to have its own javac,
> >
> >It does not, when you use the compiler plugin in the default config it
> uses the Java compiler from the JDK you started maven with. It just uses
> the Tool API instead of the cli, but itâ€™s basically same functionality.
> >
> >You have either different JDKs or the settings are different. Most likely
> you did not set a release version, since maven does not default to the JDK
> version you are building with.
> >
> >> For starters I'd like to convince maven to use one lf mine.
> >
> >You can use toolchain and fork options, but I think you mostly need to
> use correct release switch I suspect.
> >
> >
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html
> >
> >https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
> >
> >GruÃŸ
> >Bernd
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: what javac is actually used?

2023-12-03 Thread Tamás Cservenák

Howdy,

Simplest would be that in module where you found afore mentioned
differences ask for effective pom:
$ mvn help:effective-pom

Maybe pipe it to a file as it may be huge. Then look for
project/build/plugins/maven-compiler-plugin (quasi xpath).

T

On Sun, Dec 3, 2023, 22:08 Dave Dyer  wrote:

>
> >
> >Maven, by default uses maven-compiler-plugin, but that plugin itself is
> >pluggable (can use javac, which is default, but also eclipse compiler,
> etc).
> >The plugin by default uses javac.
>
> The build I'm using seems to not be using javac - where is guidance
> to configuring it?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: what javac is actually used?

2023-12-03 Thread Tamás Cservenák

Howdy,

Maven, by default uses maven-compiler-plugin, but that plugin itself is
pluggable (can use javac, which is default, but also eclipse compiler, etc).
The plugin by default uses javac.

But, for example maven compiler plugin _by default_ enables debug:
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#debug

Inferior bytecode means what in this case?

HTH
Tamas

On Sun, Dec 3, 2023 at 8:48 PM Dave Dyer  wrote:

>
> The problem I'm investigating is that the code produced by a
> maven build is different, and inferior, to the code produced
> but any javac I can find.  My questions are, what java compiler
> is it actually using, and of course, how can I change it?
>
> The best info I have is that it's using plexus-compiler-javac\2.8.4
> also, attempting to configure the maven-compiler-plugin artifact
> only changes what jdk is used to invoke the plexus compiler, not
> the compiler actually used to produce classes.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Apache Maven 3.9.6 released

2023-12-01 Thread Tamás Cservenák

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

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

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

Release Notes - Maven - Version 3.9.6

** Improvement
* [MNG-7939] - Allow to exclude plugins from validation
** Dependency upgrade
* [MNG-7913] - Upgrade Sisu version to 0.9.0.M2
* [MNG-7934] - Upgrade Resolver version to 1.9.18
* [MNG-7942] - Upgrade to parent POM 41
* [MNG-7943] - Upgrade default plugin bindings

Have fun!
- The Maven Team

[ANN] Maven Resolver 2.0.0-alpha-3 released

2023-12-01 Thread Tamás Cservenák

Howdy,

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

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

This is a third *PREVIEW* release of upcoming Maven Resolver 2.0.0 meant
for users of Resolver to pick it up and adapt code if needed.

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

** Bug
* [MRESOLVER-372] - Sporadic AccessDeniedEx on Windows
* [MRESOLVER-436] - The Upgrading Resolver page uses classnames before
rename
* [MRESOLVER-438] - The new jdk transport bug on Java 11 and Java 17
* [MRESOLVER-441] - Undo FileUtils changes that altered non-Windows
execution path
** Improvement
* [MRESOLVER-321] - Resolver while collecting may end up in busy loop
without any possibility to be stopped
** Task
* [MRESOLVER-429] - Enhance JDK transport error messaging
* [MRESOLVER-437] - Resolver should not override given HTTP transport
default use of expect-continue handshake
* [MRESOLVER-439] - Collapse "jdk" transport modules
* [MRESOLVER-440] - Clean up transport names, configuration properties
and documentation
* [MRESOLVER-442] - New JDK transport JAR mixes classes with different
bytecode
* [MRESOLVER-444] - Make build time requirement for Java 17
** Dependency upgrade
* [MRESOLVER-434] - Upgrade Parent to 41

Have fun,
Maven Team

[ANN] Maven Resolver 1.9.18 released

2023-11-25 Thread Tamás Cservenák

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

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

Resolver 1.9.17 release is declared "broken" by RM, release 1.9.18 undos
the unwanted code change that happened in FileUtils@1.9.17 and restores
source compatibility between 2.x and 1.9.x.

===

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

Release Notes - Maven Resolver - Version 1.9.18

** Bug
* [MRESOLVER-441] - Undo FileUtils changes that altered non-Windows
execution path
** Task
* [MRESOLVER-437] - Resolver should not override given HTTP transport
default use of expect-continue handshake

Have fun,
-The Apache Maven team

Re: .sha256 artifact checksums on Central

2023-11-22 Thread Tamás Cservenák

Most probably is, this should never happen.
There is NO global policy change, SHA-1 is still _mandatory_, while you CAN
add SHA256 or whatever "better" if you want... but SHA-1 is mandatory. This
should be enforced by Sonatype...

T

On Wed, Nov 22, 2023 at 5:38 PM Bernd Eckenfels 
wrote:

>
>
> Michael Osipov wrote on 22. Nov 2023 17:18 (GMT +01:00):
>
> > Look at this:
> >
> https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/
> >
> > Whatever they did, they did wrong.
>
> Microsoft is responsive in their bug tracker, will let them know.
>
> But how can you upload a incomplete submission to oss, is that a bug on
> sonatype?
>
> Gruß
> Bernd
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [ANN] Maven Resolver 1.9.17 released

2023-11-22 Thread Tamás Cservenák

Howdy,

since 1.9.17 release went out, we detected some possible problems with
1.9.17 and decided to quickly roll out 1.9.18 with two important changes:
- MRESOLVER-372 fix in 1.9.17 introduced some unwanted changes in FileUtils
non-Windows execution path (undo those),
- backport MRESOLVER-437, that altered changes happened as part of
MRESOLVER-433 that is in 1.9.17. This prevents source level breakage
between 1.9.x and 2.0.x, as backport removes a field added in (and present
only in) 1.9.17 that was in subsequent changes removed in 2.0.x.

Hence I declare 1.9.17 as <>, this version should be skipped.
Upcoming 1.9.18 will correct these issues.

Thanks
T

On Tue, Nov 21, 2023 at 11:31 AM Tamás Cservenák  wrote:

> The Apache Maven team is pleased to announce the release of the
> Maven Resolver 1.9.17:
>
> The 1.x resolver lineage is in "bugfix only" maintenance mode.
>
> ===
>
> https://maven.apache.org/resolver/
>
> Release Notes - Maven Resolver - Version 1.9.17
> ** Bug
> * [MRESOLVER-372] - Sporadic AccessDeniedEx on Windows
> ** Task
> * [MRESOLVER-433] - Expose configuration for inhibiting
> Expect-Continue handshake in 1.x
> * [MRESOLVER-435] - Refresh download page
> ** Dependency upgrade
> * [MRESOLVER-434] - Upgrade Parent to 41
>
> Have fun,
> -The Apache Maven team
>

Re: .sha256 artifact checksums on Central

Sorry, talked prematurely (and not at desk, only phone)... this is a
sonatype issue it seems. Will take a deeper look tomorrow.

T

On Tue, Nov 21, 2023, 21:11 Tamás Cservenák  wrote:

> Sha1s are present as well... Unsure what the problem is here, what do i
> miss?
>
> T
>
> On Tue, Nov 21, 2023, 20:10 Bernd Eckenfels 
> wrote:
>
>>
>>
>> Bernd Eckenfels wrote on 21. Nov 2023 19:44 (GMT +01:00):
>> > Strange enough central did accept those, but seems to not support it
>> with
>> > Remote Included Strategy (X- headers):
>>
>> Now that I thought about it, another possible explanation: I think
>> -Daether.checksums.algo=
>> rithms=SHA-256 is effectiv, all downloads WARN.
>>
>> So I suspect maven with direct connections to Central use the synthetic
>> SHA-1 checksum
>> Headers and does never miss the .sha1 files. but with a proxy-repo in
>> between it fails to do
>> that.
>>
>> I guess I need to trace more interactions along those lines.
>> Will it somehow know not to request .sha256 or does my nexus just not
>> mirror them?
>>
>> For my testing convinience, do I need a dummy Pom or can I trigger the
>> resolve with cli in exactly the same way?
>>
>>
>> Gruß
>> Bernd
>> —
>> https://bernd.eckenfels.net
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: .sha256 artifact checksums on Central

Sha1s are present as well... Unsure what the problem is here, what do i
miss?

T

On Tue, Nov 21, 2023, 20:10 Bernd Eckenfels  wrote:

>
>
> Bernd Eckenfels wrote on 21. Nov 2023 19:44 (GMT +01:00):
> > Strange enough central did accept those, but seems to not support it with
> > Remote Included Strategy (X- headers):
>
> Now that I thought about it, another possible explanation: I think
> -Daether.checksums.algo=
> rithms=SHA-256 is effectiv, all downloads WARN.
>
> So I suspect maven with direct connections to Central use the synthetic
> SHA-1 checksum
> Headers and does never miss the .sha1 files. but with a proxy-repo in
> between it fails to do
> that.
>
> I guess I need to trace more interactions along those lines.
> Will it somehow know not to request .sha256 or does my nexus just not
> mirror them?
>
> For my testing convinience, do I need a dummy Pom or can I trigger the
> resolve with cli in exactly the same way?
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 3.9.6 release is coming soon

Howdy,

Good ideas! I completely forgot about default bindings

T

On Tue, Nov 21, 2023 at 1:04 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> We can consider:
>  - update parent to 41
>  - update versions of default bindings plugins - some can have fix support
> for JDK 21 - to check
>
> wt., 21 lis 2023 o 12:22 Tamás Cservenák  napisał(a):
>
> > Howdy,
> >
> > The 3.9.6 release will contain three important changes:
> > - Resolver 1.9.x is hopefully "tamed" on Windows, no more sporadic
> > AccessDeniedEx to fail the builds
> > - Sisu DI is upgraded to support bytecode higher than Java 14. This makes
> > writing Maven components (extensions, plugins, Sisu managed JSR330
> > components) using bytecode higher than Java 14 possible. Naturally, to
> have
> > those used in your build, you will also have to raise the Maven runtime
> > Java requirement, and have it aligned with your new components.
> > - ability to exclude plugin from plugin validation (as an "escape hatch")
> >
> > As usual, if anyone has anything to add, please speak up!
> >
> > Thanks
> > T
> >
>
>
> --
> Sławomir Jaranowski
>

Maven 3.9.6 release is coming soon

Howdy,

The 3.9.6 release will contain three important changes:
- Resolver 1.9.x is hopefully "tamed" on Windows, no more sporadic
AccessDeniedEx to fail the builds
- Sisu DI is upgraded to support bytecode higher than Java 14. This makes
writing Maven components (extensions, plugins, Sisu managed JSR330
components) using bytecode higher than Java 14 possible. Naturally, to have
those used in your build, you will also have to raise the Maven runtime
Java requirement, and have it aligned with your new components.
- ability to exclude plugin from plugin validation (as an "escape hatch")

As usual, if anyone has anything to add, please speak up!

Thanks
T

[ANN] Maven Resolver 1.9.17 released