You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2025/10/15 18:42:53 UTC
[DISCUSS] Prepare for 4.0.0 release
Hey everyone,
We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
to cut the 4.0.0 release.
Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
so that it works properly on JDK 17, 21, and 25 (we can later bump to the
upcoming parent once it includes the same change).
The release notes [1] currently only show the diffs since RC4, so we should
probably do another pass on the “What’s New in Maven 4” page [3] — to
highlight the new mvnup upgrade tool (from rc-4) and double-check that
everything important is covered (if you see anything missing, please yell).
Any objections to this plan? If not, shall we go ahead?
Cheers,
Guillaume Nodet
[1]
https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
[2] https://github.com/apache/maven/pull/11275
[3] https://maven.apache.org/whatsnewinmaven4.html
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Martin Desruisseaux <ma...@geomatys.com.INVALID>.
+1 for a release. A last 4.0.0-rc-5 (which would actually be the first
real release candidate) is also fine for me. I'm familiar with only a
small part of Maven core, but for the part that I'm familiar with,
pretty much everything is in place.
Martin
Le 15/10/2025 à 20:42, Guillaume Nodet a écrit :
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we should
> probably do another pass on the “What’s New in Maven 4” page [3] — to
> highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[HEADS UP] Reverting consumer POM flattening and targeting rc-5 (was: [DISCUSS] Prepare for 4.0.0 release)
Posted by Guillaume Nodet <gn...@apache.org>.
I had planned to finish the few remaining issues raised for 4.0.x and
release a GA this week, but with Tamas, we found some problems caused by
the flattening of the consumer POM, especially with the new transitive
dependency manager.
So we think that we should revert that change and disable the flattening of
the consumer POM by default. The feature is still present, but needs to be
enabled using -Dmaven.consumer.pom.flatten. A side effect is also a
performance boost, as creating the consumer POM won't require collecting
the dependency tree again.
See https://github.com/apache/maven/pull/11347
Given this is a somewhat important change, I'm now planning to do a rc-5 in
the coming days.
Cheers,
Guillaume
Le mer. 15 oct. 2025 à 20:42, Guillaume Nodet <gn...@apache.org> a écrit :
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> [2] so that it works properly on JDK 17, 21, and 25 (we can later bump to
> the upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we
> should probably do another pass on the “What’s New in Maven 4” page [3] —
> to highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Guillaume Nodet <gn...@apache.org>.
Hi Vladimir,
It does not seem those issues are bugs that would require a fix a few days
before GA.
If there's a consensus to move on that, it could be done for 4.1
(eventually with an opt-in or opt-out flag).
Cheers,
Guillaume
Le mar. 21 oct. 2025 à 16:58, Vladimir Sitnikov <si...@gmail.com>
a écrit :
> I've tested dependency resolution issues
> with apache-maven-4.0.0-20251021.130451-109-bin.zip, and both issues still
> reproduce.
>
> * https://lists.apache.org/thread/q0bn38qtxkv4orx6o9lhtonjcxkbtw5f
> * https://lists.apache.org/thread/8o67zmfjyjv9k44tnqooh1cbfzt3xf8o
>
> Vladimir
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've tested dependency resolution issues
with apache-maven-4.0.0-20251021.130451-109-bin.zip, and both issues still
reproduce.
* https://lists.apache.org/thread/q0bn38qtxkv4orx6o9lhtonjcxkbtw5f
* https://lists.apache.org/thread/8o67zmfjyjv9k44tnqooh1cbfzt3xf8o
Vladimir
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Sergey Chernov <se...@gmail.com>.
> The subset project execution hangs (specified via "-pl" parameter)
> I've created an issue with some details
https://github.com/apache/maven/issues/11302 (IMO blocker)
Apologies, by mistake I was testing beta-5 which is not the latest (it was
late Oct 2024, not 2025). The latest SNAPSHOT does not have this problem
anymore (closed).
Also the build time is way better now (mvn3 - 3 min, mvn4 - 4 min).
The `mvn4 clean` takes just 3 sec on empty 1000 modules project!
On Mon, Oct 20, 2025 at 2:08 PM Sergey Chernov <se...@gmail.com>
wrote:
> The subset project execution hangs (specified via "-pl" parameter)
> I've created an issue with some details
> https://github.com/apache/maven/issues/11302 (IMO blocker)
> If I'm not mistaken, there were similar problems with Maven 3 that were
> eventually addressed.
>
> On Mon, Oct 20, 2025 at 1:29 PM Sergey Chernov <se...@gmail.com>
> wrote:
>
>> 1.
>> > This has been fixed a few months ago.
>> > See https://github.com/apache/maven-wrapper/pull/335
>> > You need to update your wrapper scripts, the problem is not in maven
>> itself.
>>
>> Indeed, after updating to Maven Wrapper to 3.3.4 the problem is gone,
>> thanks. Also I see the beta-5 is available on maven central
>> /4.0.0-beta-5/apache-maven-4.0.0-beta-5-bin.zip
>>
>> > ---
>> > Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
>> The
>> > following artifacts could not be resolved:
>> > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
>> >
>> > com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-
>> extension-v0.0.5-alpha1.jar
>> > NOT allowed from central (
>> > https://registry.acme.com:443/registry/java-registry
>> <https://registry.acme.com/registry/java-registry>, default,
>> > releases+snapshots)
>> > Those exceptions are a shortcut to avoid unnecessary HTTP requests to
>> the repository
>> > which is known to not have a given groupId.
>> > More information could be interesting to investigate, but this is not
>> > supposed to change the outcome.
>>
>> How the Maven makes a decision which groupId are available and which are
>> not, as the repository configuration looks like this in `settings.xml`:
>> ```
>> <repositories>
>> <repository>
>> <snapshots>
>> <enabled>false</enabled>
>> </snapshots>
>> <id>central</id>
>> <name>java-virtual</name>
>> <url>https://registry.acme.com:443/java-registry</url>
>> </repository>
>> <repository>
>> <snapshots />
>> <id>snapshots</id>
>> <name>java-virtual</name>
>> <url>https://registry.acme.com:443/java-registry</url>
>> </repository>
>> </repositories>
>> ```
>> (similar for pluginRepositories). There are no explicitly specified
>> wildcards which groupIds are allowed and which are not. So I'd expect the
>> old behavior is preserved iterating all known registries.
>> Can you please elaborate more on this new changed logic of artifact
>> resolving. Is there any migration instruction related? Or which exact
>> details I can share to help discover this?
>>
>> 5.
>> > You can disable it using `-Dmaven.consumer.pom=false`.
>> Thanks. I assumed that's the bottleneck of the build, but it's still slow.
>> For comparison, for the monolith project with 1000 modules (monolith =
>> it's assembled to a single Docker artifact) with empty "target" directories
>> and all resolved .m2 artifacts:
>> `mvn3 clean` takes 2 sec, while `mvn4 clean` takes 34 seconds (it builds
>> the model slowly).
>> The build of this project (with all artifacts already downloaded) is
>> about twice longer (mvn3 - almost 3 min, mvn4 - almost 7 min).
>>
>> I don't think it's a blocker for releasing Maven 4, but a reason for us
>> to stay on Maven 3 at least for now.
>>
>>
>> On Fri, Oct 17, 2025 at 7:52 AM Guillaume Nodet <gn...@apache.org>
>> wrote:
>>
>>> Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <se...@gmail.com> a
>>> écrit :
>>>
>>> > 1.
>>> > > We have nightly builds available at
>>> > >
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
>>> >
>>> > If such URL is specified in the maven-wrapper.properties
>>> > ```
>>> > distributionUrl=
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip
>>> > ```
>>> >
>>> > the build fails with
>>> > ```
>>> > ./mvnw -v
>>> > ./mvnw: line 255:
>>> >
>>> >
>>> /var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url:
>>> > No such file or directory
>>> > ```
>>> > This was already discussed. So I'd like to request to fix this before
>>> the
>>> > release. It will simplify testing a lot in CI/CD environments (as you
>>> just
>>> > need to change the URL instead of cloning the maven repo, switching to
>>> > correct branch which is not master BTW, calling version:set, making a
>>> build
>>> > and uploading to your local registry). Please consider this if you'd
>>> like
>>> > to increase the early adoption of release candidates (any simple
>>> impediment
>>> > reduces it drastically).
>>> >
>>>
>>> This has been fixed a few months ago.
>>> See https://github.com/apache/maven-wrapper/pull/335
>>> You need to update your wrapper scripts, the problem is not in maven
>>> itself.
>>>
>>>
>>> >
>>> > Alternatively (also) it could be great to release rc5 which can be
>>> easily
>>> > used in mvnw. As there were many changes since rc4.
>>> >
>>> > 2. I tested fresh 4.0.x maven with several projects locally, including
>>> > those which have custom plugins as well as lots of modules (1000).
>>> > Great news, fresh version are significantly faster after these problems
>>> > were addressed (thanks Tamas and everybody who contributed there).
>>> > But please note that the build is still slower ~45-60%. This is not
>>> > critical but may be a reason not to switch to 4.0.0 release right now
>>> for
>>> > us.
>>> > I believe the biggest bottleneck is aggregating flat list of transitive
>>> > dependencies (see paragraph 5 below about listing transitive/direct
>>> > dependencies).
>>> >
>>>
>>> See below.
>>>
>>>
>>> > 3. If all dependencies are downloaded, build is fine. But there are
>>> build
>>> > failures related to resolving artifacts with a very misleading message
>>> like
>>> > (note that the real dependency name is a bit different as it's
>>> private):
>>> > ```
>>> > Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException:
>>> Prefix
>>> >
>>> >
>>> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
>>> > NOT allowed from central (
>>> > https://registry.acme.com:443/registry/java-registry, default,
>>> releases)
>>> > at
>>> >
>>> >
>>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267)
>>> > at
>>> >
>>> >
>>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
>>> > at
>>> >
>>> >
>>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298)
>>> > ---
>>> > Caused by:
>>> org.eclipse.aether.resolution.DependencyResolutionException: The
>>> > following artifacts could not be resolved:
>>> > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
>>> >
>>> >
>>> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
>>> > NOT allowed from central (
>>> > https://registry.acme.com:443/registry/java-registry, default,
>>> > releases+snapshots)
>>> > at
>>> >
>>> >
>>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311)
>>> > at
>>> >
>>> >
>>> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268)
>>> > ```
>>> > I could not fix this. What's the "filter", what's the "prefix", how is
>>> it
>>> > configured? I checked the setting.xml schema 1.2.0 and could not find
>>> any
>>> > relevant tags for it. I checked the Maven 4 release notes and could not
>>> > find any related info. In the debugger I've found some dictionary with
>>> > elements like
>>> > ```
>>> > "commons-net" -> {Node@5994} "?commons-net"
>>> > "jxta" -> {Node@5996} "?jxta"
>>> > "excalibur-extension" -> {Node@5998} "?excalibur-extension"
>>> > "directory-clients" -> {Node@6000} "?directory-clients"
>>> > "easyconf" -> {Node@6002} "?easyconf"
>>> > ...
>>> > ```
>>> > which looks like a set of fraud dependencies (perhaps). The failure
>>> message
>>> > gives zero clarity on it. This may be a blocker for many projects.
>>> E.g. for
>>> > our codebase lots on internal dependencies are now blocked (not
>>> central or
>>> > fork and potentially fraud, but pure internal). Maybe I'm wrong and
>>> it's
>>> > not fraud, but a version number with "alpha" in it or with versions
>>> based
>>> > on the current timestamp.
>>> >
>>>
>>> Those exceptions are a shortcut to avoid unnecessary HTTP requests to the
>>> repository
>>> which is known to not have a given groupId.
>>> More information could be interesting to investigate, but this is not
>>> supposed to
>>> change the outcome.
>>>
>>>
>>>
>>> > 4. I'd like to run CI tests as well, but because of 3 I'm blocked.
>>> >
>>>
>>> Well, as above...
>>>
>>>
>>> >
>>> > 5. AFAIK there is a brand-new conception of fat/thin POMs for
>>> > export/deployment. And these "build" poms now list the plain list of
>>> all
>>> > transitive dependencies.
>>> > First: let's make it alphabetically sorted as it's not possible no
>>> navigate
>>> > thru the huge list of randomly ordered (probably it's a HashMap
>>> iteration).
>>> > Second: WDYT to opt-in old behavior for cases when I don't want a flat
>>> > list? E.g. we have aggregating modules that refer to the other
>>> aggregating
>>> > modules. Imagine a composite spring-boot-starter listing all other
>>> -starter
>>> > modules. As a flat list it's immense and unreadable (some of our POMs
>>> are
>>> > more than 100KB). In most scenarios this can be ok to use flat list by
>>> > default, but if there is a choice to use old implementation and only
>>> list
>>> > direct it would be awesome.
>>> >
>>>
>>> The build POM is the one you write, which is deployed with a "-build"
>>> classifier.
>>> The consumer POM does not flatten the direct dependencies. But it
>>> flattens
>>> the _managed_ dependencies which are _actually used_. The exact process
>>> if the following:
>>>
>>> for each managed dep in the model:
>>> * if there is no corresponding node in the tree, discard the managed dep
>>> * if there's a direct dependency, apply the managed dependency to it
>>> and discard the managed dep
>>> * else keep the managed dep
>>>
>>> filter out direct dependencies which have a non-transitive scope
>>>
>>> remove managed dependencies which are direct dependencies
>>>
>>> That POM is not supposed to be user-friendly, but rather
>>> computer-friendly.
>>>
>>> You can disable it using `-Dmaven.consumer.pom=false`.
>>>
>>> If your POM is 100 kB long, that's because you have a huge transitive
>>> graph
>>> with lots of managed dependencies. You should not have more managed
>>> dependencies in your consumer POM that the number of transitive
>>> dependencies.
>>> Reducing the size of the dependency tree of your artifacts can be a good
>>> idea.
>>>
>>> On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <ah...@gmail.com>
>>> wrote:
>>> >
>>> > > +1
>>> > >
>>> > > Well done team
>>> > >
>>> > > Arnaud Héritier
>>> > > GitHub/ASF/... : aheritier
>>> > >
>>> > >
>>> > > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>> > >
>>> > > > Hey everyone,
>>> > > >
>>> > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think
>>> it’s
>>> > time
>>> > > > to cut the 4.0.0 release.
>>> > > > Before that, I’d just like to get the Spotless/Palantir plugin
>>> upgraded
>>> > > [2]
>>> > > > so that it works properly on JDK 17, 21, and 25 (we can later bump
>>> to
>>> > the
>>> > > > upcoming parent once it includes the same change).
>>> > > >
>>> > > > The release notes [1] currently only show the diffs since RC4, so
>>> we
>>> > > should
>>> > > > probably do another pass on the “What’s New in Maven 4” page [3] —
>>> to
>>> > > > highlight the new mvnup upgrade tool (from rc-4) and double-check
>>> that
>>> > > > everything important is covered (if you see anything missing,
>>> please
>>> > > yell).
>>> > > >
>>> > > > Any objections to this plan? If not, shall we go ahead?
>>> > > >
>>> > > > Cheers,
>>> > > > Guillaume Nodet
>>> > > >
>>> > > > [1]
>>> > > >
>>> > >
>>> >
>>> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
>>> > > > [2] https://github.com/apache/maven/pull/11275
>>> > > > [3] https://maven.apache.org/whatsnewinmaven4.html
>>> > > >
>>> > >
>>> >
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Sergey Chernov <se...@gmail.com>.
The subset project execution hangs (specified via "-pl" parameter)
I've created an issue with some details
https://github.com/apache/maven/issues/11302 (IMO blocker)
If I'm not mistaken, there were similar problems with Maven 3 that were
eventually addressed.
On Mon, Oct 20, 2025 at 1:29 PM Sergey Chernov <se...@gmail.com>
wrote:
> 1.
> > This has been fixed a few months ago.
> > See https://github.com/apache/maven-wrapper/pull/335
> > You need to update your wrapper scripts, the problem is not in maven
> itself.
>
> Indeed, after updating to Maven Wrapper to 3.3.4 the problem is gone,
> thanks. Also I see the beta-5 is available on maven central
> /4.0.0-beta-5/apache-maven-4.0.0-beta-5-bin.zip
>
> > ---
> > Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
> The
> > following artifacts could not be resolved:
> > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
> >
> > com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-
> extension-v0.0.5-alpha1.jar
> > NOT allowed from central (
> > https://registry.acme.com:443/registry/java-registry
> <https://registry.acme.com/registry/java-registry>, default,
> > releases+snapshots)
> > Those exceptions are a shortcut to avoid unnecessary HTTP requests to
> the repository
> > which is known to not have a given groupId.
> > More information could be interesting to investigate, but this is not
> > supposed to change the outcome.
>
> How the Maven makes a decision which groupId are available and which are
> not, as the repository configuration looks like this in `settings.xml`:
> ```
> <repositories>
> <repository>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> <id>central</id>
> <name>java-virtual</name>
> <url>https://registry.acme.com:443/java-registry</url>
> </repository>
> <repository>
> <snapshots />
> <id>snapshots</id>
> <name>java-virtual</name>
> <url>https://registry.acme.com:443/java-registry</url>
> </repository>
> </repositories>
> ```
> (similar for pluginRepositories). There are no explicitly specified
> wildcards which groupIds are allowed and which are not. So I'd expect the
> old behavior is preserved iterating all known registries.
> Can you please elaborate more on this new changed logic of artifact
> resolving. Is there any migration instruction related? Or which exact
> details I can share to help discover this?
>
> 5.
> > You can disable it using `-Dmaven.consumer.pom=false`.
> Thanks. I assumed that's the bottleneck of the build, but it's still slow.
> For comparison, for the monolith project with 1000 modules (monolith =
> it's assembled to a single Docker artifact) with empty "target" directories
> and all resolved .m2 artifacts:
> `mvn3 clean` takes 2 sec, while `mvn4 clean` takes 34 seconds (it builds
> the model slowly).
> The build of this project (with all artifacts already downloaded) is about
> twice longer (mvn3 - almost 3 min, mvn4 - almost 7 min).
>
> I don't think it's a blocker for releasing Maven 4, but a reason for us to
> stay on Maven 3 at least for now.
>
>
> On Fri, Oct 17, 2025 at 7:52 AM Guillaume Nodet <gn...@apache.org> wrote:
>
>> Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <se...@gmail.com> a
>> écrit :
>>
>> > 1.
>> > > We have nightly builds available at
>> > >
>> >
>> >
>> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
>> >
>> > If such URL is specified in the maven-wrapper.properties
>> > ```
>> > distributionUrl=
>> >
>> >
>> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip
>> > ```
>> >
>> > the build fails with
>> > ```
>> > ./mvnw -v
>> > ./mvnw: line 255:
>> >
>> >
>> /var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url:
>> > No such file or directory
>> > ```
>> > This was already discussed. So I'd like to request to fix this before
>> the
>> > release. It will simplify testing a lot in CI/CD environments (as you
>> just
>> > need to change the URL instead of cloning the maven repo, switching to
>> > correct branch which is not master BTW, calling version:set, making a
>> build
>> > and uploading to your local registry). Please consider this if you'd
>> like
>> > to increase the early adoption of release candidates (any simple
>> impediment
>> > reduces it drastically).
>> >
>>
>> This has been fixed a few months ago.
>> See https://github.com/apache/maven-wrapper/pull/335
>> You need to update your wrapper scripts, the problem is not in maven
>> itself.
>>
>>
>> >
>> > Alternatively (also) it could be great to release rc5 which can be
>> easily
>> > used in mvnw. As there were many changes since rc4.
>> >
>> > 2. I tested fresh 4.0.x maven with several projects locally, including
>> > those which have custom plugins as well as lots of modules (1000).
>> > Great news, fresh version are significantly faster after these problems
>> > were addressed (thanks Tamas and everybody who contributed there).
>> > But please note that the build is still slower ~45-60%. This is not
>> > critical but may be a reason not to switch to 4.0.0 release right now
>> for
>> > us.
>> > I believe the biggest bottleneck is aggregating flat list of transitive
>> > dependencies (see paragraph 5 below about listing transitive/direct
>> > dependencies).
>> >
>>
>> See below.
>>
>>
>> > 3. If all dependencies are downloaded, build is fine. But there are
>> build
>> > failures related to resolving artifacts with a very misleading message
>> like
>> > (note that the real dependency name is a bit different as it's private):
>> > ```
>> > Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException:
>> Prefix
>> >
>> >
>> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
>> > NOT allowed from central (
>> > https://registry.acme.com:443/registry/java-registry, default,
>> releases)
>> > at
>> >
>> >
>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267)
>> > at
>> >
>> >
>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
>> > at
>> >
>> >
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298)
>> > ---
>> > Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
>> The
>> > following artifacts could not be resolved:
>> > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
>> >
>> >
>> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
>> > NOT allowed from central (
>> > https://registry.acme.com:443/registry/java-registry, default,
>> > releases+snapshots)
>> > at
>> >
>> >
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311)
>> > at
>> >
>> >
>> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268)
>> > ```
>> > I could not fix this. What's the "filter", what's the "prefix", how is
>> it
>> > configured? I checked the setting.xml schema 1.2.0 and could not find
>> any
>> > relevant tags for it. I checked the Maven 4 release notes and could not
>> > find any related info. In the debugger I've found some dictionary with
>> > elements like
>> > ```
>> > "commons-net" -> {Node@5994} "?commons-net"
>> > "jxta" -> {Node@5996} "?jxta"
>> > "excalibur-extension" -> {Node@5998} "?excalibur-extension"
>> > "directory-clients" -> {Node@6000} "?directory-clients"
>> > "easyconf" -> {Node@6002} "?easyconf"
>> > ...
>> > ```
>> > which looks like a set of fraud dependencies (perhaps). The failure
>> message
>> > gives zero clarity on it. This may be a blocker for many projects. E.g.
>> for
>> > our codebase lots on internal dependencies are now blocked (not central
>> or
>> > fork and potentially fraud, but pure internal). Maybe I'm wrong and it's
>> > not fraud, but a version number with "alpha" in it or with versions
>> based
>> > on the current timestamp.
>> >
>>
>> Those exceptions are a shortcut to avoid unnecessary HTTP requests to the
>> repository
>> which is known to not have a given groupId.
>> More information could be interesting to investigate, but this is not
>> supposed to
>> change the outcome.
>>
>>
>>
>> > 4. I'd like to run CI tests as well, but because of 3 I'm blocked.
>> >
>>
>> Well, as above...
>>
>>
>> >
>> > 5. AFAIK there is a brand-new conception of fat/thin POMs for
>> > export/deployment. And these "build" poms now list the plain list of all
>> > transitive dependencies.
>> > First: let's make it alphabetically sorted as it's not possible no
>> navigate
>> > thru the huge list of randomly ordered (probably it's a HashMap
>> iteration).
>> > Second: WDYT to opt-in old behavior for cases when I don't want a flat
>> > list? E.g. we have aggregating modules that refer to the other
>> aggregating
>> > modules. Imagine a composite spring-boot-starter listing all other
>> -starter
>> > modules. As a flat list it's immense and unreadable (some of our POMs
>> are
>> > more than 100KB). In most scenarios this can be ok to use flat list by
>> > default, but if there is a choice to use old implementation and only
>> list
>> > direct it would be awesome.
>> >
>>
>> The build POM is the one you write, which is deployed with a "-build"
>> classifier.
>> The consumer POM does not flatten the direct dependencies. But it
>> flattens
>> the _managed_ dependencies which are _actually used_. The exact process
>> if the following:
>>
>> for each managed dep in the model:
>> * if there is no corresponding node in the tree, discard the managed dep
>> * if there's a direct dependency, apply the managed dependency to it
>> and discard the managed dep
>> * else keep the managed dep
>>
>> filter out direct dependencies which have a non-transitive scope
>>
>> remove managed dependencies which are direct dependencies
>>
>> That POM is not supposed to be user-friendly, but rather
>> computer-friendly.
>>
>> You can disable it using `-Dmaven.consumer.pom=false`.
>>
>> If your POM is 100 kB long, that's because you have a huge transitive
>> graph
>> with lots of managed dependencies. You should not have more managed
>> dependencies in your consumer POM that the number of transitive
>> dependencies.
>> Reducing the size of the dependency tree of your artifacts can be a good
>> idea.
>>
>> On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <ah...@gmail.com>
>> wrote:
>> >
>> > > +1
>> > >
>> > > Well done team
>> > >
>> > > Arnaud Héritier
>> > > GitHub/ASF/... : aheritier
>> > >
>> > >
>> > > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org>
>> wrote:
>> > >
>> > > > Hey everyone,
>> > > >
>> > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s
>> > time
>> > > > to cut the 4.0.0 release.
>> > > > Before that, I’d just like to get the Spotless/Palantir plugin
>> upgraded
>> > > [2]
>> > > > so that it works properly on JDK 17, 21, and 25 (we can later bump
>> to
>> > the
>> > > > upcoming parent once it includes the same change).
>> > > >
>> > > > The release notes [1] currently only show the diffs since RC4, so we
>> > > should
>> > > > probably do another pass on the “What’s New in Maven 4” page [3] —
>> to
>> > > > highlight the new mvnup upgrade tool (from rc-4) and double-check
>> that
>> > > > everything important is covered (if you see anything missing, please
>> > > yell).
>> > > >
>> > > > Any objections to this plan? If not, shall we go ahead?
>> > > >
>> > > > Cheers,
>> > > > Guillaume Nodet
>> > > >
>> > > > [1]
>> > > >
>> > >
>> >
>> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
>> > > > [2] https://github.com/apache/maven/pull/11275
>> > > > [3] https://maven.apache.org/whatsnewinmaven4.html
>> > > >
>> > >
>> >
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Sergey Chernov <se...@gmail.com>.
1.
> This has been fixed a few months ago.
> See https://github.com/apache/maven-wrapper/pull/335
> You need to update your wrapper scripts, the problem is not in maven
itself.
Indeed, after updating to Maven Wrapper to 3.3.4 the problem is gone,
thanks. Also I see the beta-5 is available on maven central
/4.0.0-beta-5/apache-maven-4.0.0-beta-5-bin.zip
> ---
> Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
The
> following artifacts could not be resolved:
> com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
>
> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-
extension-v0.0.5-alpha1.jar
> NOT allowed from central (
> https://registry.acme.com:443/registry/java-registry
<https://registry.acme.com/registry/java-registry>, default,
> releases+snapshots)
> Those exceptions are a shortcut to avoid unnecessary HTTP requests to the
repository
> which is known to not have a given groupId.
> More information could be interesting to investigate, but this is not
> supposed to change the outcome.
How the Maven makes a decision which groupId are available and which are
not, as the repository configuration looks like this in `settings.xml`:
```
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>central</id>
<name>java-virtual</name>
<url>https://registry.acme.com:443/java-registry</url>
</repository>
<repository>
<snapshots />
<id>snapshots</id>
<name>java-virtual</name>
<url>https://registry.acme.com:443/java-registry</url>
</repository>
</repositories>
```
(similar for pluginRepositories). There are no explicitly specified
wildcards which groupIds are allowed and which are not. So I'd expect the
old behavior is preserved iterating all known registries.
Can you please elaborate more on this new changed logic of artifact
resolving. Is there any migration instruction related? Or which exact
details I can share to help discover this?
5.
> You can disable it using `-Dmaven.consumer.pom=false`.
Thanks. I assumed that's the bottleneck of the build, but it's still slow.
For comparison, for the monolith project with 1000 modules (monolith = it's
assembled to a single Docker artifact) with empty "target" directories and
all resolved .m2 artifacts:
`mvn3 clean` takes 2 sec, while `mvn4 clean` takes 34 seconds (it builds
the model slowly).
The build of this project (with all artifacts already downloaded) is about
twice longer (mvn3 - almost 3 min, mvn4 - almost 7 min).
I don't think it's a blocker for releasing Maven 4, but a reason for us to
stay on Maven 3 at least for now.
On Fri, Oct 17, 2025 at 7:52 AM Guillaume Nodet <gn...@apache.org> wrote:
> Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <se...@gmail.com> a
> écrit :
>
> > 1.
> > > We have nightly builds available at
> > >
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
> >
> > If such URL is specified in the maven-wrapper.properties
> > ```
> > distributionUrl=
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip
> > ```
> >
> > the build fails with
> > ```
> > ./mvnw -v
> > ./mvnw: line 255:
> >
> >
> /var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url:
> > No such file or directory
> > ```
> > This was already discussed. So I'd like to request to fix this before the
> > release. It will simplify testing a lot in CI/CD environments (as you
> just
> > need to change the URL instead of cloning the maven repo, switching to
> > correct branch which is not master BTW, calling version:set, making a
> build
> > and uploading to your local registry). Please consider this if you'd like
> > to increase the early adoption of release candidates (any simple
> impediment
> > reduces it drastically).
> >
>
> This has been fixed a few months ago.
> See https://github.com/apache/maven-wrapper/pull/335
> You need to update your wrapper scripts, the problem is not in maven
> itself.
>
>
> >
> > Alternatively (also) it could be great to release rc5 which can be easily
> > used in mvnw. As there were many changes since rc4.
> >
> > 2. I tested fresh 4.0.x maven with several projects locally, including
> > those which have custom plugins as well as lots of modules (1000).
> > Great news, fresh version are significantly faster after these problems
> > were addressed (thanks Tamas and everybody who contributed there).
> > But please note that the build is still slower ~45-60%. This is not
> > critical but may be a reason not to switch to 4.0.0 release right now for
> > us.
> > I believe the biggest bottleneck is aggregating flat list of transitive
> > dependencies (see paragraph 5 below about listing transitive/direct
> > dependencies).
> >
>
> See below.
>
>
> > 3. If all dependencies are downloaded, build is fine. But there are build
> > failures related to resolving artifacts with a very misleading message
> like
> > (note that the real dependency name is a bit different as it's private):
> > ```
> > Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException:
> Prefix
> >
> >
> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
> > NOT allowed from central (
> > https://registry.acme.com:443/registry/java-registry, default, releases)
> > at
> >
> >
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267)
> > at
> >
> >
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
> > at
> >
> >
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298)
> > ---
> > Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
> The
> > following artifacts could not be resolved:
> > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
> >
> >
> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
> > NOT allowed from central (
> > https://registry.acme.com:443/registry/java-registry, default,
> > releases+snapshots)
> > at
> >
> >
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311)
> > at
> >
> >
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268)
> > ```
> > I could not fix this. What's the "filter", what's the "prefix", how is it
> > configured? I checked the setting.xml schema 1.2.0 and could not find any
> > relevant tags for it. I checked the Maven 4 release notes and could not
> > find any related info. In the debugger I've found some dictionary with
> > elements like
> > ```
> > "commons-net" -> {Node@5994} "?commons-net"
> > "jxta" -> {Node@5996} "?jxta"
> > "excalibur-extension" -> {Node@5998} "?excalibur-extension"
> > "directory-clients" -> {Node@6000} "?directory-clients"
> > "easyconf" -> {Node@6002} "?easyconf"
> > ...
> > ```
> > which looks like a set of fraud dependencies (perhaps). The failure
> message
> > gives zero clarity on it. This may be a blocker for many projects. E.g.
> for
> > our codebase lots on internal dependencies are now blocked (not central
> or
> > fork and potentially fraud, but pure internal). Maybe I'm wrong and it's
> > not fraud, but a version number with "alpha" in it or with versions based
> > on the current timestamp.
> >
>
> Those exceptions are a shortcut to avoid unnecessary HTTP requests to the
> repository
> which is known to not have a given groupId.
> More information could be interesting to investigate, but this is not
> supposed to
> change the outcome.
>
>
>
> > 4. I'd like to run CI tests as well, but because of 3 I'm blocked.
> >
>
> Well, as above...
>
>
> >
> > 5. AFAIK there is a brand-new conception of fat/thin POMs for
> > export/deployment. And these "build" poms now list the plain list of all
> > transitive dependencies.
> > First: let's make it alphabetically sorted as it's not possible no
> navigate
> > thru the huge list of randomly ordered (probably it's a HashMap
> iteration).
> > Second: WDYT to opt-in old behavior for cases when I don't want a flat
> > list? E.g. we have aggregating modules that refer to the other
> aggregating
> > modules. Imagine a composite spring-boot-starter listing all other
> -starter
> > modules. As a flat list it's immense and unreadable (some of our POMs are
> > more than 100KB). In most scenarios this can be ok to use flat list by
> > default, but if there is a choice to use old implementation and only list
> > direct it would be awesome.
> >
>
> The build POM is the one you write, which is deployed with a "-build"
> classifier.
> The consumer POM does not flatten the direct dependencies. But it flattens
> the _managed_ dependencies which are _actually used_. The exact process
> if the following:
>
> for each managed dep in the model:
> * if there is no corresponding node in the tree, discard the managed dep
> * if there's a direct dependency, apply the managed dependency to it
> and discard the managed dep
> * else keep the managed dep
>
> filter out direct dependencies which have a non-transitive scope
>
> remove managed dependencies which are direct dependencies
>
> That POM is not supposed to be user-friendly, but rather
> computer-friendly.
>
> You can disable it using `-Dmaven.consumer.pom=false`.
>
> If your POM is 100 kB long, that's because you have a huge transitive graph
> with lots of managed dependencies. You should not have more managed
> dependencies in your consumer POM that the number of transitive
> dependencies.
> Reducing the size of the dependency tree of your artifacts can be a good
> idea.
>
> On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <ah...@gmail.com>
> wrote:
> >
> > > +1
> > >
> > > Well done team
> > >
> > > Arnaud Héritier
> > > GitHub/ASF/... : aheritier
> > >
> > >
> > > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org>
> wrote:
> > >
> > > > Hey everyone,
> > > >
> > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s
> > time
> > > > to cut the 4.0.0 release.
> > > > Before that, I’d just like to get the Spotless/Palantir plugin
> upgraded
> > > [2]
> > > > so that it works properly on JDK 17, 21, and 25 (we can later bump to
> > the
> > > > upcoming parent once it includes the same change).
> > > >
> > > > The release notes [1] currently only show the diffs since RC4, so we
> > > should
> > > > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > > > highlight the new mvnup upgrade tool (from rc-4) and double-check
> that
> > > > everything important is covered (if you see anything missing, please
> > > yell).
> > > >
> > > > Any objections to this plan? If not, shall we go ahead?
> > > >
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > > > [2] https://github.com/apache/maven/pull/11275
> > > > [3] https://maven.apache.org/whatsnewinmaven4.html
> > > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Guillaume Nodet <gn...@apache.org>.
Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <se...@gmail.com> a
écrit :
> 1.
> > We have nightly builds available at
> >
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
>
> If such URL is specified in the maven-wrapper.properties
> ```
> distributionUrl=
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip
> ```
>
> the build fails with
> ```
> ./mvnw -v
> ./mvnw: line 255:
>
> /var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url:
> No such file or directory
> ```
> This was already discussed. So I'd like to request to fix this before the
> release. It will simplify testing a lot in CI/CD environments (as you just
> need to change the URL instead of cloning the maven repo, switching to
> correct branch which is not master BTW, calling version:set, making a build
> and uploading to your local registry). Please consider this if you'd like
> to increase the early adoption of release candidates (any simple impediment
> reduces it drastically).
>
This has been fixed a few months ago.
See https://github.com/apache/maven-wrapper/pull/335
You need to update your wrapper scripts, the problem is not in maven itself.
>
> Alternatively (also) it could be great to release rc5 which can be easily
> used in mvnw. As there were many changes since rc4.
>
> 2. I tested fresh 4.0.x maven with several projects locally, including
> those which have custom plugins as well as lots of modules (1000).
> Great news, fresh version are significantly faster after these problems
> were addressed (thanks Tamas and everybody who contributed there).
> But please note that the build is still slower ~45-60%. This is not
> critical but may be a reason not to switch to 4.0.0 release right now for
> us.
> I believe the biggest bottleneck is aggregating flat list of transitive
> dependencies (see paragraph 5 below about listing transitive/direct
> dependencies).
>
See below.
> 3. If all dependencies are downloaded, build is fine. But there are build
> failures related to resolving artifacts with a very misleading message like
> (note that the real dependency name is a bit different as it's private):
> ```
> Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException: Prefix
>
> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
> NOT allowed from central (
> https://registry.acme.com:443/registry/java-registry, default, releases)
> at
>
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267)
> at
>
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
> at
>
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298)
> ---
> Caused by: org.eclipse.aether.resolution.DependencyResolutionException: The
> following artifacts could not be resolved:
> com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
>
> com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
> NOT allowed from central (
> https://registry.acme.com:443/registry/java-registry, default,
> releases+snapshots)
> at
>
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311)
> at
>
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268)
> ```
> I could not fix this. What's the "filter", what's the "prefix", how is it
> configured? I checked the setting.xml schema 1.2.0 and could not find any
> relevant tags for it. I checked the Maven 4 release notes and could not
> find any related info. In the debugger I've found some dictionary with
> elements like
> ```
> "commons-net" -> {Node@5994} "?commons-net"
> "jxta" -> {Node@5996} "?jxta"
> "excalibur-extension" -> {Node@5998} "?excalibur-extension"
> "directory-clients" -> {Node@6000} "?directory-clients"
> "easyconf" -> {Node@6002} "?easyconf"
> ...
> ```
> which looks like a set of fraud dependencies (perhaps). The failure message
> gives zero clarity on it. This may be a blocker for many projects. E.g. for
> our codebase lots on internal dependencies are now blocked (not central or
> fork and potentially fraud, but pure internal). Maybe I'm wrong and it's
> not fraud, but a version number with "alpha" in it or with versions based
> on the current timestamp.
>
Those exceptions are a shortcut to avoid unnecessary HTTP requests to the
repository
which is known to not have a given groupId.
More information could be interesting to investigate, but this is not
supposed to
change the outcome.
> 4. I'd like to run CI tests as well, but because of 3 I'm blocked.
>
Well, as above...
>
> 5. AFAIK there is a brand-new conception of fat/thin POMs for
> export/deployment. And these "build" poms now list the plain list of all
> transitive dependencies.
> First: let's make it alphabetically sorted as it's not possible no navigate
> thru the huge list of randomly ordered (probably it's a HashMap iteration).
> Second: WDYT to opt-in old behavior for cases when I don't want a flat
> list? E.g. we have aggregating modules that refer to the other aggregating
> modules. Imagine a composite spring-boot-starter listing all other -starter
> modules. As a flat list it's immense and unreadable (some of our POMs are
> more than 100KB). In most scenarios this can be ok to use flat list by
> default, but if there is a choice to use old implementation and only list
> direct it would be awesome.
>
The build POM is the one you write, which is deployed with a "-build"
classifier.
The consumer POM does not flatten the direct dependencies. But it flattens
the _managed_ dependencies which are _actually used_. The exact process
if the following:
for each managed dep in the model:
* if there is no corresponding node in the tree, discard the managed dep
* if there's a direct dependency, apply the managed dependency to it
and discard the managed dep
* else keep the managed dep
filter out direct dependencies which have a non-transitive scope
remove managed dependencies which are direct dependencies
That POM is not supposed to be user-friendly, but rather computer-friendly.
You can disable it using `-Dmaven.consumer.pom=false`.
If your POM is 100 kB long, that's because you have a huge transitive graph
with lots of managed dependencies. You should not have more managed
dependencies in your consumer POM that the number of transitive
dependencies.
Reducing the size of the dependency tree of your artifacts can be a good
idea.
On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <ah...@gmail.com> wrote:
>
> > +1
> >
> > Well done team
> >
> > Arnaud Héritier
> > GitHub/ASF/... : aheritier
> >
> >
> > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org> wrote:
> >
> > > Hey everyone,
> > >
> > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s
> time
> > > to cut the 4.0.0 release.
> > > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> > [2]
> > > so that it works properly on JDK 17, 21, and 25 (we can later bump to
> the
> > > upcoming parent once it includes the same change).
> > >
> > > The release notes [1] currently only show the diffs since RC4, so we
> > should
> > > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > > everything important is covered (if you see anything missing, please
> > yell).
> > >
> > > Any objections to this plan? If not, shall we go ahead?
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > [1]
> > >
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > > [2] https://github.com/apache/maven/pull/11275
> > > [3] https://maven.apache.org/whatsnewinmaven4.html
> > >
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Sergey Chernov <se...@gmail.com>.
1.
> We have nightly builds available at
>
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
If such URL is specified in the maven-wrapper.properties
```
distributionUrl=
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip
```
the build fails with
```
./mvnw -v
./mvnw: line 255:
/var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url:
No such file or directory
```
This was already discussed. So I'd like to request to fix this before the
release. It will simplify testing a lot in CI/CD environments (as you just
need to change the URL instead of cloning the maven repo, switching to
correct branch which is not master BTW, calling version:set, making a build
and uploading to your local registry). Please consider this if you'd like
to increase the early adoption of release candidates (any simple impediment
reduces it drastically).
Alternatively (also) it could be great to release rc5 which can be easily
used in mvnw. As there were many changes since rc4.
2. I tested fresh 4.0.x maven with several projects locally, including
those which have custom plugins as well as lots of modules (1000).
Great news, fresh version are significantly faster after these problems
were addressed (thanks Tamas and everybody who contributed there).
But please note that the build is still slower ~45-60%. This is not
critical but may be a reason not to switch to 4.0.0 release right now for
us.
I believe the biggest bottleneck is aggregating flat list of transitive
dependencies (see paragraph 5 below about listing transitive/direct
dependencies).
3. If all dependencies are downloaded, build is fine. But there are build
failures related to resolving artifacts with a very misleading message like
(note that the real dependency name is a bit different as it's private):
```
Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException: Prefix
com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
NOT allowed from central (
https://registry.acme.com:443/registry/java-registry, default, releases)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298)
---
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: The
following artifacts could not be resolved:
com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix
com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar
NOT allowed from central (
https://registry.acme.com:443/registry/java-registry, default,
releases+snapshots)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311)
at
org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268)
```
I could not fix this. What's the "filter", what's the "prefix", how is it
configured? I checked the setting.xml schema 1.2.0 and could not find any
relevant tags for it. I checked the Maven 4 release notes and could not
find any related info. In the debugger I've found some dictionary with
elements like
```
"commons-net" -> {Node@5994} "?commons-net"
"jxta" -> {Node@5996} "?jxta"
"excalibur-extension" -> {Node@5998} "?excalibur-extension"
"directory-clients" -> {Node@6000} "?directory-clients"
"easyconf" -> {Node@6002} "?easyconf"
...
```
which looks like a set of fraud dependencies (perhaps). The failure message
gives zero clarity on it. This may be a blocker for many projects. E.g. for
our codebase lots on internal dependencies are now blocked (not central or
fork and potentially fraud, but pure internal). Maybe I'm wrong and it's
not fraud, but a version number with "alpha" in it or with versions based
on the current timestamp.
4. I'd like to run CI tests as well, but because of 3 I'm blocked.
5. AFAIK there is a brand-new conception of fat/thin POMs for
export/deployment. And these "build" poms now list the plain list of all
transitive dependencies.
First: let's make it alphabetically sorted as it's not possible no navigate
thru the huge list of randomly ordered (probably it's a HashMap iteration).
Second: WDYT to opt-in old behavior for cases when I don't want a flat
list? E.g. we have aggregating modules that refer to the other aggregating
modules. Imagine a composite spring-boot-starter listing all other -starter
modules. As a flat list it's immense and unreadable (some of our POMs are
more than 100KB). In most scenarios this can be ok to use flat list by
default, but if there is a choice to use old implementation and only list
direct it would be awesome.
On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <ah...@gmail.com> wrote:
> +1
>
> Well done team
>
> Arnaud Héritier
> GitHub/ASF/... : aheritier
>
>
> On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org> wrote:
>
> > Hey everyone,
> >
> > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> > to cut the 4.0.0 release.
> > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> [2]
> > so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> > upcoming parent once it includes the same change).
> >
> > The release notes [1] currently only show the diffs since RC4, so we
> should
> > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > everything important is covered (if you see anything missing, please
> yell).
> >
> > Any objections to this plan? If not, shall we go ahead?
> >
> > Cheers,
> > Guillaume Nodet
> >
> > [1]
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > [2] https://github.com/apache/maven/pull/11275
> > [3] https://maven.apache.org/whatsnewinmaven4.html
> >
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Arnaud Héritier <ah...@gmail.com>.
+1
Well done team
Arnaud Héritier
GitHub/ASF/... : aheritier
On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <gn...@apache.org> wrote:
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we should
> probably do another pass on the “What’s New in Maven 4” page [3] — to
> highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Dmitriy Smirnov <dm...@jetbrains.com.INVALID>.
Hello Maven developers,
Thank you all for your hard work — it’s exciting to see Maven 4.0.0
approaching release! We’re all looking forward to it.
For those of us building integrations on top of Maven (think IDEs and
various plugins), a release candidate as close as possible to the final
version would be extremely helpful. This would allow us to properly
validate our builds against it.
At JetBrains, and I’m sure across the broader ecosystem, we would greatly
appreciate having an RC5 available ahead of the final release.
Thank you once again for your continued efforts!
Best regards,
Dmitriy Smirnov
JetBrains
On Thu, Oct 16, 2025 at 12:15 PM Sandra Parsick <sa...@parsick.dev> wrote:
> +1
>
> Thank you for your hard work. 🙏
>
> Am 15.10.25 um 20:42 schrieb Guillaume Nodet:
> > Hey everyone,
> >
> > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> > to cut the 4.0.0 release.
> > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> [2]
> > so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> > upcoming parent once it includes the same change).
> >
> > The release notes [1] currently only show the diffs since RC4, so we
> should
> > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > everything important is covered (if you see anything missing, please
> yell).
> >
> > Any objections to this plan? If not, shall we go ahead?
> >
> > Cheers,
> > Guillaume Nodet
> >
> > [1]
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > [2] https://github.com/apache/maven/pull/11275
> > [3] https://maven.apache.org/whatsnewinmaven4.html
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Sandra Parsick <sa...@parsick.dev>.
+1
Thank you for your hard work. 🙏
Am 15.10.25 um 20:42 schrieb Guillaume Nodet:
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we should
> probably do another pass on the “What’s New in Maven 4” page [3] — to
> highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Javaccino founder (Java/.NET service - contact via linkedin)
Le jeu. 16 oct. 2025 à 07:43, Olivier Lamy <ol...@apache.org> a écrit :
> Awesome.
> Bravo all for the hard work.
>
> On Thu, 16 Oct 2025 at 15:27, Guillaume Nodet <gn...@apache.org> wrote:
> >
> > We have nightly builds available at
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
> >
> > Le mer. 15 oct. 2025 à 23:33, Mateusz Gajewski <
> > mateusz.gajewski@starburstdata.com> a écrit :
> >
> > > Hi,
> > >
> > > Is there already a staged build that we could test before actual
> release?
> > > :)
> > >
> > > On Wed, Oct 15, 2025 at 10:41 PM Matthias Bünger <mb...@apache.org>
> > > wrote:
> > >
> > > > Hi all, hi Guillaume,
> > > >
> > > > thanks for your hard work! As already written in some other post last
> > > > week (?) I'm really looking forward for the final release.
> > > >
> > > > I've created a site issue [A] to collect the things to add/update in
> the
> > > > article and will update the article with them. So please add
> everything
> > > > you think missing there (with a ressource maybe ;) ). While creating
> the
> > > > the issue I only added the missing upgrade tool, but will go through
> the
> > > > release notes myself most probably on friday.
> > > >
> > > > Have a good night everyone
> > > >
> > > > Matthias
> > > >
> > > >
> > > > [A] https://github.com/apache/maven-site/issues/1428
> > > >
> > > > Am 15.10.2025 um 20:42 schrieb Guillaume Nodet:
> > > > > Hey everyone,
> > > > >
> > > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think
> it’s
> > > time
> > > > > to cut the 4.0.0 release.
> > > > > Before that, I’d just like to get the Spotless/Palantir plugin
> upgraded
> > > > [2]
> > > > > so that it works properly on JDK 17, 21, and 25 (we can later bump
> to
> > > the
> > > > > upcoming parent once it includes the same change).
> > > > >
> > > > > The release notes [1] currently only show the diffs since RC4, so
> we
> > > > should
> > > > > probably do another pass on the “What’s New in Maven 4” page [3] —
> to
> > > > > highlight the new mvnup upgrade tool (from rc-4) and double-check
> that
> > > > > everything important is covered (if you see anything missing,
> please
> > > > yell).
> > > > >
> > > > > Any objections to this plan? If not, shall we go ahead?
> > > > >
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > > > > [2] https://github.com/apache/maven/pull/11275
> > > > > [3] https://maven.apache.org/whatsnewinmaven4.html
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Olivier Lamy <ol...@apache.org>.
Awesome.
Bravo all for the hard work.
On Thu, 16 Oct 2025 at 15:27, Guillaume Nodet <gn...@apache.org> wrote:
>
> We have nightly builds available at
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
>
> Le mer. 15 oct. 2025 à 23:33, Mateusz Gajewski <
> mateusz.gajewski@starburstdata.com> a écrit :
>
> > Hi,
> >
> > Is there already a staged build that we could test before actual release?
> > :)
> >
> > On Wed, Oct 15, 2025 at 10:41 PM Matthias Bünger <mb...@apache.org>
> > wrote:
> >
> > > Hi all, hi Guillaume,
> > >
> > > thanks for your hard work! As already written in some other post last
> > > week (?) I'm really looking forward for the final release.
> > >
> > > I've created a site issue [A] to collect the things to add/update in the
> > > article and will update the article with them. So please add everything
> > > you think missing there (with a ressource maybe ;) ). While creating the
> > > the issue I only added the missing upgrade tool, but will go through the
> > > release notes myself most probably on friday.
> > >
> > > Have a good night everyone
> > >
> > > Matthias
> > >
> > >
> > > [A] https://github.com/apache/maven-site/issues/1428
> > >
> > > Am 15.10.2025 um 20:42 schrieb Guillaume Nodet:
> > > > Hey everyone,
> > > >
> > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s
> > time
> > > > to cut the 4.0.0 release.
> > > > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> > > [2]
> > > > so that it works properly on JDK 17, 21, and 25 (we can later bump to
> > the
> > > > upcoming parent once it includes the same change).
> > > >
> > > > The release notes [1] currently only show the diffs since RC4, so we
> > > should
> > > > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > > > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > > > everything important is covered (if you see anything missing, please
> > > yell).
> > > >
> > > > Any objections to this plan? If not, shall we go ahead?
> > > >
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > > [1]
> > > >
> > >
> > https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > > > [2] https://github.com/apache/maven/pull/11275
> > > > [3] https://maven.apache.org/whatsnewinmaven4.html
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Guillaume Nodet <gn...@apache.org>.
We have nightly builds available at
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/
Le mer. 15 oct. 2025 à 23:33, Mateusz Gajewski <
mateusz.gajewski@starburstdata.com> a écrit :
> Hi,
>
> Is there already a staged build that we could test before actual release?
> :)
>
> On Wed, Oct 15, 2025 at 10:41 PM Matthias Bünger <mb...@apache.org>
> wrote:
>
> > Hi all, hi Guillaume,
> >
> > thanks for your hard work! As already written in some other post last
> > week (?) I'm really looking forward for the final release.
> >
> > I've created a site issue [A] to collect the things to add/update in the
> > article and will update the article with them. So please add everything
> > you think missing there (with a ressource maybe ;) ). While creating the
> > the issue I only added the missing upgrade tool, but will go through the
> > release notes myself most probably on friday.
> >
> > Have a good night everyone
> >
> > Matthias
> >
> >
> > [A] https://github.com/apache/maven-site/issues/1428
> >
> > Am 15.10.2025 um 20:42 schrieb Guillaume Nodet:
> > > Hey everyone,
> > >
> > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s
> time
> > > to cut the 4.0.0 release.
> > > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> > [2]
> > > so that it works properly on JDK 17, 21, and 25 (we can later bump to
> the
> > > upcoming parent once it includes the same change).
> > >
> > > The release notes [1] currently only show the diffs since RC4, so we
> > should
> > > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > > everything important is covered (if you see anything missing, please
> > yell).
> > >
> > > Any objections to this plan? If not, shall we go ahead?
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > [1]
> > >
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > > [2] https://github.com/apache/maven/pull/11275
> > > [3] https://maven.apache.org/whatsnewinmaven4.html
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Mateusz Gajewski <ma...@starburstdata.com>.
Hi,
Is there already a staged build that we could test before actual release? :)
On Wed, Oct 15, 2025 at 10:41 PM Matthias Bünger <mb...@apache.org>
wrote:
> Hi all, hi Guillaume,
>
> thanks for your hard work! As already written in some other post last
> week (?) I'm really looking forward for the final release.
>
> I've created a site issue [A] to collect the things to add/update in the
> article and will update the article with them. So please add everything
> you think missing there (with a ressource maybe ;) ). While creating the
> the issue I only added the missing upgrade tool, but will go through the
> release notes myself most probably on friday.
>
> Have a good night everyone
>
> Matthias
>
>
> [A] https://github.com/apache/maven-site/issues/1428
>
> Am 15.10.2025 um 20:42 schrieb Guillaume Nodet:
> > Hey everyone,
> >
> > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> > to cut the 4.0.0 release.
> > Before that, I’d just like to get the Spotless/Palantir plugin upgraded
> [2]
> > so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> > upcoming parent once it includes the same change).
> >
> > The release notes [1] currently only show the diffs since RC4, so we
> should
> > probably do another pass on the “What’s New in Maven 4” page [3] — to
> > highlight the new mvnup upgrade tool (from rc-4) and double-check that
> > everything important is covered (if you see anything missing, please
> yell).
> >
> > Any objections to this plan? If not, shall we go ahead?
> >
> > Cheers,
> > Guillaume Nodet
> >
> > [1]
> >
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> > [2] https://github.com/apache/maven/pull/11275
> > [3] https://maven.apache.org/whatsnewinmaven4.html
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Matthias Bünger <mb...@apache.org>.
Hi all, hi Guillaume,
thanks for your hard work! As already written in some other post last
week (?) I'm really looking forward for the final release.
I've created a site issue [A] to collect the things to add/update in the
article and will update the article with them. So please add everything
you think missing there (with a ressource maybe ;) ). While creating the
the issue I only added the missing upgrade tool, but will go through the
release notes myself most probably on friday.
Have a good night everyone
Matthias
[A] https://github.com/apache/maven-site/issues/1428
Am 15.10.2025 um 20:42 schrieb Guillaume Nodet:
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we should
> probably do another pass on the “What’s New in Maven 4” page [3] — to
> highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Maarten Mulders <mt...@apache.org>.
We might want to do a similar thing for Apache Maven Daemon, by the way.
I think Daemon is still on 4.0.0-rc-3, which is even older.
It's been way too long since I cut Maven releases (and I think I never
ever cut a release of Core) so I'm a bit hesitant to step up and offer
to do it myself. I'll be more than happy to test-drive any new RC's though!
Maarten
On 16/10/2025 11:04, Maarten Mulders wrote:
> Absolutely no objections, I would very much like to see 4.0.0 happen!
>
> Would it make sense to cut a 4.0.0-rc-5 release with the aim of
> gathering feedback, and the promise of "this will be 4.0.0 if no major
> issues are found"?
>
> One way or another, thanks for stepping forward and taking the
> initiative. Also big thanks for everyone who contributed in small or in
> large to getting this far!
>
>
> Maarten
>
> On 15/10/2025 20:42, Guillaume Nodet wrote:
>> Hey everyone,
>>
>> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
>> to cut the 4.0.0 release.
>> Before that, I’d just like to get the Spotless/Palantir plugin
>> upgraded [2]
>> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
>> upcoming parent once it includes the same change).
>>
>> The release notes [1] currently only show the diffs since RC4, so we
>> should
>> probably do another pass on the “What’s New in Maven 4” page [3] — to
>> highlight the new mvnup upgrade tool (from rc-4) and double-check that
>> everything important is covered (if you see anything missing, please
>> yell).
>>
>> Any objections to this plan? If not, shall we go ahead?
>>
>> Cheers,
>> Guillaume Nodet
>>
>> [1]
>> https://github.com/apache/maven/releases/tag/
>> untagged-269a18e49ead47082a92
>> [2] https://github.com/apache/maven/pull/11275
>> [3] https://maven.apache.org/whatsnewinmaven4.html
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Prepare for 4.0.0 release
Posted by Maarten Mulders <mt...@apache.org>.
Absolutely no objections, I would very much like to see 4.0.0 happen!
Would it make sense to cut a 4.0.0-rc-5 release with the aim of
gathering feedback, and the promise of "this will be 4.0.0 if no major
issues are found"?
One way or another, thanks for stepping forward and taking the
initiative. Also big thanks for everyone who contributed in small or in
large to getting this far!
Maarten
On 15/10/2025 20:42, Guillaume Nodet wrote:
> Hey everyone,
>
> We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s time
> to cut the 4.0.0 release.
> Before that, I’d just like to get the Spotless/Palantir plugin upgraded [2]
> so that it works properly on JDK 17, 21, and 25 (we can later bump to the
> upcoming parent once it includes the same change).
>
> The release notes [1] currently only show the diffs since RC4, so we should
> probably do another pass on the “What’s New in Maven 4” page [3] — to
> highlight the new mvnup upgrade tool (from rc-4) and double-check that
> everything important is covered (if you see anything missing, please yell).
>
> Any objections to this plan? If not, shall we go ahead?
>
> Cheers,
> Guillaume Nodet
>
> [1]
> https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92
> [2] https://github.com/apache/maven/pull/11275
> [3] https://maven.apache.org/whatsnewinmaven4.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org