Re: [HEADS UP] Maven 3.9.10 release
No problems with latest 3.9.10-SNAPSHOT (1da6ce512) on the company projects. On Tue, May 27, 2025 at 5:43 PM Filipe Roque wrote: > On Mon, 2025-05-26 at 21:22 +0200, Slawomir Jaranowski wrote: > > dev distribution updated: > > > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.10-SNAPSHOT/ > > svnid: 77141 > > > > Apache Maven 3.9.10-SNAPSHOT > > (1da6ce51230b0b3247c983ec25bdeae21d52395f) > > > > No problems detected for me on the company projects. > > Filipe Roque >
Re: [HEADS UP] Maven 3.9.10 release
Thanks everybody for testing. I hope to prepare a release at the weekend, so it should be published after voting next week. On Thu, 29 May 2025 at 19:11, Sergey Chernov wrote: > No problems with latest 3.9.10-SNAPSHOT (1da6ce512) on the company > projects. > > On Tue, May 27, 2025 at 5:43 PM Filipe Roque > wrote: > > > On Mon, 2025-05-26 at 21:22 +0200, Slawomir Jaranowski wrote: > > > dev distribution updated: > > > > > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.10-SNAPSHOT/ > > > svnid: 77141 > > > > > > Apache Maven 3.9.10-SNAPSHOT > > > (1da6ce51230b0b3247c983ec25bdeae21d52395f) > > > > > > > No problems detected for me on the company projects. > > > > Filipe Roque > > > -- Sławomir Jaranowski
Re: [VOTE] Release Apache Maven Clean Plugin version 3.5.0
+1 On Wed, 28 May 2025 at 08:21, Slawomir Jaranowski wrote: > > Hi, > > We solved 6 issues: > https://github.com/apache/maven-clean-plugin/milestone/5?closed=1 > > There are still a couple of issues left: > https://github.com/apache/maven-clean-plugin/issues > > Changes since the last release: > https://github.com/apache/maven-clean-plugin/compare/maven-clean-plugin-3.4.1...maven-clean-plugin-3.5.0 > > Staging repo: > https://repository.apache.org/content/repositories/maven-2292/ > https://repository.apache.org/content/repositories/maven-2292/org/apache/maven/plugins/maven-clean-plugin/3.5.0/maven-clean-plugin-3.5.0-source-release.zip > > Source release checksum(s): > maven-clean-plugin-3.5.0-source-release.zip - SHA-512 : > ce4b6c59ff2efa9312b2c607507efb015d1caf5f21cdb09c92ce4eea751cf2b586c9984532d3788ffedae1a544f806524ab99540dab7b2252322ae8f94380d21 > > Staging site: > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > NOTE - site build with local patch: > https://github.com/apache/maven-clean-plugin/pull/255 > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
all running with skipTests log4j both success, mvn3 2:00 mvn4 1:50 dubbo both success, mvn3 3:08 mvn4 3:19 hadoop failed due to network reason(for yarn frontend, well considering about where I'm living it is normal...) for structs 2, 90%+ time is wasted on antrun for docs generation in struts2-assembly. both mvn3 and mvn4 be very very slow there. jetty seems has profile-plugin leak when using mvn4. maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project, which is only defined in a profile (named `config`) which shall not be on. quarkus cannot build with mvn4, maven-invoker-plugin failed Xeno Amess 于2025年5月29日周四 14:52写道: > nope. neither can the github master latest. > > Xeno Amess 于2025年5月29日周四 14:40写道: > >> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest >> github code version... >> >> Xeno Amess 于2025年5月29日周四 14:39写道: >> >>> jetty is a good example. >>> mvn3 can build but mvn4 cannot. >>> >>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project >>> >>> [INFO] ---< org.eclipse.jetty.ee10:jetty-ee10-bom >>> > >>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT >>> [90/354] >>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml >>> [INFO] [ pom >>> ]- >>> [INFO] Going to calculate checksum for project >>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom, >>> version=12.0.22-SNAPSHOT] >>> [INFO] Project inputs calculated in 0 ms. XXMM checksum >>> [7b7b6120251dfd1d] calculated in 0 ms. >>> [INFO] Attempting to restore project >>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache >>> [INFO] Local build found by checksum 7b7b6120251dfd1d >>> [INFO] Found cached build, restoring >>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum >>> 7b7b6120251dfd1d >>> [WARNING] Cached build doesn't contains all requested plugin executions >>> (missing: >>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources >>> {execution: copy-resources}, >>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution: >>> config-assembly}]), cannot restore >>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for >>> org.eclipse.jetty.ee10:jetty-ee10-bom >>> [INFO] >>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom --- >>> [INFO] Index file does not exist. Fallback to an empty index >>> [INFO] Sorting file /tmp/pom11239457262347372795.xml >>> [INFO] Pom file is already sorted, exiting >>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be >>> clean, 1 were already clean, 0 were skipped because caching determined they >>> were already clean >>> [INFO] >>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom --- >>> [INFO] 开始检查…… >>> 检查完成。 >>> [INFO] You have 0 Checkstyle violations. >>> [INFO] >>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @ >>> jetty-ee10-bom --- >>> [INFO] Rule 0: >>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed >>> [INFO] >>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom --- >>> [INFO] Rule 3: >>> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule) >>> passed >>> [INFO] Rule 4: >>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed >>> [INFO] >>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @ >>> jetty-ee10-bom --- >>> [INFO] >>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @ >>> jetty-ee10-bom --- >>> [INFO] argLine set to >>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/** >>> [INFO] >>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @ >>> jetty-ee10-bom --- >>> [INFO] invoker.mavenOpts set to >>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/** >>> [INFO] >>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @ >>> jetty-ee
Re: https://github.com/seregamorph/maven-turbo-reactor
Hey, Delany. > I'm running with this extension going forward. I don't use the build cache (yet) so that's not an issue. I recommend you to try https://github.com/seregamorph/maven-surefire-cached (free) which is compatible with this extension (and supports jacoco reports as well). > We have one huge module though (project we're calling it now) with extensive tests, and its a bottleneck for all that follow. Exactly. This is the type of the bottleneck that this extension solves. > I did notice jacoco coverage was disabled as I bound the jacoco-maven-plugin report goal to the prepare-package phase. The jacoco should work. Maybe indeed the phase of the plugin should be adjusted. Feel free to contact me directly or submit an issue request on github. > But can you make it work with the buildplan-maven-plugin:list-phases goal so I can actually see which phases runs when, or is that up to this plugin to figure out? Thank you very much for this question! It's addressed now (and also mentioned in the readme), please try extension version 0.3 with the fix. On Tue, May 27, 2025 at 10:17 PM Sergey Chernov wrote: > Hey, Guillaume. > > Thanks for your feedback, I appreciate it. > > > Regarding your suggestion about upfront downloads > > It was my reflection (assumption) about takari-smart-builder, the turbo > builder does not load upfront. > > > The Maven 4 concurrent builder decomposes projects at the phase level > > This is nice. This looks somehow similar to how Gradle is scheduling tasks > graph (instead of modules) having granular build graph. I was also thinking > this direction as long-term goal. > > > I’d love to hear more about your PoC and explore how it could inform > Maven’s evolution. Have you considered testing it against Maven 4’s > concurrent builder to compare performance and compatibility? > > To be honest, I wasn't aware about this refactoring in Maven 4 (all > discussions I've seen were focused on the separate deployed POM feature). I > will take a look for sure. Unfortunately, first experiments with building > project locally on Maven 4 are not promising regarding performance (for > clarity: I removed all extensions to avoid side effects of non-standard > solutions). If you can give some guidance how can I inspect bottlenecks of > the Maven 4 builds, it would be great. I tried to analyze it via VisualVM - > there is no obvious heap or thread leakage. But it looks like the maven > build is gradually loosing speed - the logs are printed slower and slower. > I think I can try takari-timeline (BTW I 😍 it), but not sure it'll give > answers. Theoretically this can be related to kotlin plugin, I don't know. > > On Tue, May 27, 2025 at 9:51 PM Guillaume Nodet wrote: > >> Hi Sergey, >> >> Your maven-turbo-builder sounds very similar to the concurrent builder >> in Maven 4, so I’d like to share some insights for comparison. >> >> The Maven 4 concurrent builder decomposes projects at the phase level, >> with phases ordered based on fine-grained constraints. Unlike the >> traditional builder, these constraints allow more flexibility. For >> instance, if project A depends on project B at test scope, both can >> start building concurrently, but A’s test phase will wait until B >> completes its necessary phases (e.g., resource preparation, >> compilation, and class post-processing) to ensure the required >> artifacts are available. Downloads are deferred to avoid pausing the >> build unnecessarily, which aligns with optimizing build performance. >> >> To maintain compatibility with existing Maven behavior, the standard >> phase order is preserved. However, with the concurrent builder, phases >> form a dependency tree rather than a linear list, as detailed in the >> Maven 4 lifecycle documentation [1]. This structure allows phases like >> package to run independently of test, and intra-project dependencies >> can rely on a ready phase, which precedes package. This enables >> earlier scheduling of downstream tasks. >> >> Regarding your suggestion about upfront downloads, I agree it could be >> beneficial to initiate downloads early with a strategy to prioritize >> artifacts as needed. However, since dependency downloads typically >> occur only once per project, their impact on overall build time may be >> less significant compared to phase scheduling optimizations. >> >> The maven-turbo-builder’s approach—scheduling downstream builds after >> the upstream package phase and reordering test before package—is an >> interesting optimization. It seems to align with the concurrent >> builder’s philosophy but takes a more aggressive stance by breaking >> from traditional phase ordering. Your reported 20m to 14m reduction in >> build time for a large project like Miro’s monolith is impressive and >> highlights the potential of such optimizations on multi-core systems. >> >> I’d love to hear more about your PoC and explore how it could inform >> Maven’s evolution. Have you considered testing it against Maven 4’s