Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <[email protected]> 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 <[email protected]> wrote: > > > +1 > > > > Well done team > > > > Arnaud Héritier > > GitHub/ASF/... : aheritier > > > > > > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <[email protected]> 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
