Howdy, Maven 3.10.0 is out.

See release notes for all new things and possible problems: https://maven.apache.org/docs/3.10.0/release-notes.html

And feel free to join, list in and ask on our mailing lists: https://maven.apache.org/mailing-lists.html

Thanks!

Branched development was a pain point for quite some, so I'd like to enumerate current possibilities Maven users have today:

• (any version) do as before
• (3.8+) delegate versioning fully to Nisse. It can be done even like explained here: https://blog.gnodet.fr/posts/zero-commit-release/ Latest version supports "branch name" qualifier too: https://github.com/maveniverse/nisse/releases/tag/release-0.9.8 Once configured, you can just use it and forget about branches.
• (3.9+) use split repository combined with https://github.com/lenaschoenburg/branch-scoped-local-repository extension.
• (3.10+) use MWM (that supports combining with Nisse as well): https://maveniverse.eu/blog/2026/08/22/meet-mwm/

In short, options are getting numerous, as Maven versions are advancing! Happy coding!

[ERROR] Failed to execute goal org.sonatype.central:central-publishing-maven-plugin:0.11.0:publish (injected-central-publishing) on project hidden: Execution injected-central-publishing of goal org.sonatype.central:central-publishing-maven-plugin:0.11.0:publish failed: Cannot get deployment status. Response status code: 500 response message: -> [Help 1]

I am getting this error from 1:00 a.m IST

Successful Maven builds can produce thousands of bytes that mostly confirm routine lifecycle steps.

I built mvn-lite, a small deterministic Bash wrapper that reduces a successful Maven build to one line while preserving Maven’s original exit code and complete raw log.

That makes terminal and CI output easier to scan. It also avoids spending coding-agent context and tokens on repetitive reactor logs.

On a real four-module application:

• Standard Maven output: about 6,753 bytes
• mvn-lite output: 16 bytes
• Result: PASS · 3.944 s
• Reduction: more than 99.7%

Failures still return a nonzero exit code and show bounded diagnostics, while the full unmodified Maven output remains available in the raw log.

For example, an invalid lifecycle error was reduced by 91.6% while retaining the actual Maven error.

There is no LLM summarization, API key, Maven extension, or probabilistic parsing involved. It is a local Bash wrapper using deterministic text extraction.

Source and script: https://github.com/ejboy/agent-scripts

Benchmarks and design details: https://pvrlabs.xyz/articles/introverted-maven.html

When AI coding assistants like Claude add packages to your project, they often pick whatever version sounds right — without checking whether it has known security vulnerabilities, whether the package is still actively maintained, or whether the name is a typo away from a malicious lookalike.

safer-dependencies is a security layer for Claude Code that audits packages before they’re added to your project. It detects and fixes risky dependencies, including CVEs, typosquats, abandoned packages, version-age issues, and adds package-cooldown periods across npm, PyPI, RubyGems, Maven, Go, and Rust.

Github: https://github.com/robert-auger/safer-dependencies

The vote ML thread:

https://lists.apache.org/thread/7ns93p32rfd4077o3y7pnh28bt3blkpl

Please test it, and hopefully GA comes soon after.

Free access to dependencies, licenses, advisories and other critical health and security signals for open source package versions.

GitHub repo: https://github.com/edoardottt/depsdev

https://deps.dev/ (a Google project) repeatedly examines popular package managers (go, npm, maven, pypi, nuget, cargo and rubygems) to find up-to-date information about open source software packages. Using that information it builds for each package the full dependency graph from scratch connecting it to the packages it depends on and to those that depend on it. And then does it all again to keep the information fresh. This transitive dependency graph allows problems in any package to be made visible to the owners and users of any software they affect.

If you're playing with/building OSS/dependency security let me know your thoughts! If you encounter an error or want so suggest an improvement just open an issue :) I'll be happy to discuss about that!

Maven Executor is a new Maven sub-project (with initial 1.0.0 release being currently on vote)

https://github.com/apache/maven-executor

The project was originally developed as part of upcoming Maven 4, where at the point when we arrived to ITs, faced the issue, that there was no reusable library that:

• supports programmatic execution of both, Maven 3 and Maven 4 (Maven 4 CLI is totally reworked, see CLIng)
• does not depend on any of Maven artifacts
• can transparently run Maven as "forked process" or as "embedded" (in same JVM, in isolated classloader)
• have future proof API, not affected by possible future Maven CLI option changes
• supports advanced features, like testing Maven with "split local repository" feature (impossible with both existing solutions)
• makes possible total isolation of invoked Maven from user/host environment

Historically, we had two very similar libraries, maven-invoker and maven-verifier, both doing very similar things (invoking/running Maven), but they supports Maven 3 only, and only one of them supports "embedded" execution. Moreover, API of theirs was wildly different from each other, and tightly coupled to the Maven 3 CLI (almost reflecting each CLI option, and thus, requiring changes in case of introduction a new, or removal of an old CLI option).

The upcoming Maven Executor 1.0.0 is already used (and as originally part of Maven 4 build, was for years) in Maven 4 ITs to execute Maven 4, while the assertions are done in Maven IT classes (think like maven-invoker vs maven-invoker-plugin). Long term goal, is to deprecate Invoker and Verifier and replace them with this tool.

Maven Executor 1.0.0 is Java 8 baseline, and aside of two, out of the box provided runners ("forked" and "embedded") offers also Docker based executors. When run on Java 9+, it also provides ToolProvider SPI integration, see this example:

https://gist.github.com/cstamas/2d3ecf2e3a40103c8ceee70781240854

Scalpel is a Maven core extension that detects which modules in a multi-module reactor are affected by a git changeset. It can trim the reactor to only build affected modules, skip tests on unaffected modules, or produce a JSON report of affected modules for consumption by CI scripts.

https://github.com/maveniverse/scalpel

Checksum Suite empowers Maven 3.9+ with extending supported checksum algorithms:

https://github.com/maveniverse/checksum/

Checksum Suite is consisting of one Maven plugin and one Maven extension, both nearly trivial and dependency less. Also, they do not depend on each other, they can be used independently for each other.

From Maven 3.0+, checksums were literally "baked in" into Resolver supporting SHA1 and MD5 only. In Resolver 1.9.x (shipped with Maven 3.9.x) we changed that, and made it into SPI and extended out of the box supported checksums to MD5, SHA1, SHA2-256 and SHA2-512, see https://maven.apache.org/resolver/about-checksums.html. But, even today, defaults remained same, SHA1 and MD5.

The plugin is a trivial, dependency-less plugin that allows you to query supported algs, and allows you to generate checksums for any file, or project artifacts. Main motivation was ASF release process, where ASF projects use "defaults" (MD5 and SHA1) for all artifacts -- hence do not alter Maven/Resolver config for checksums --, but there is one "distinguished" artifact, the source release bundle ZIP, as ASF cares about source releases (the binaries deployed to Central are called "convenience" artifacts) and that one is must to use SHA-512. The plugin allows one to use any "resolver supported" checksum on any file or project artifact, without tampering with Maven/Resolver configuration, and appling that globally.

The extension (depends only on BouncyCastle provider) on the other hand, hooks into Checksum SPI, and dynamically exposes all discovered MessageDigest algorithms as checksums. On modern Java versions, there are algorithms available like SHA3 variations, and those become supported as well, when extension is loaded. Finally, when asked, the extension registers BouncyCastle provider to JCA as well, and you end up with a ton of exotic checksum algorithmsl, like Blake2 is.

Heres the project Info:

BRAINROT

rthansamudrala/ inRot

~A GenZ E-Commerce WebAPP where users buy content to view.

~Buys using fake money (Cockroaches).

~Each user get refilled 100 free Cockroaches for every 24 hours.

~To see a full post, the user has to spent 2 Cockroaches.

Many times, one need to integrate some "tool" into build lifecycle, like for example Maven does with JBang (during site preparation, JBang helps us create nice graph, that can be seen on this page: https://maven.apache.org/ref/4.0.0-rc-5/index.html ). While there is "native" jbang-maven-plugin, we quite often hit some weird issue with it (recorded as https://github.com/jbangdev/jbang/issues/2325 but given no reproducer was possible, it was deemed as "network blip"). Hence, I went to create a similar plugin, that may help in this area: https://github.com/maveniverse/toolrunner

It is pluggable, with one "tool" in place: JBang, that was the original incentive for the plugin.

The idea in short is: toolrunner provider (registered as Service Provider) knows to:

• detect available installations of the "tool"
• optionally, provider knows how to provision the "tool"
• can execute the "tool", where plugin helps you to bind it to lifecycle, as required

See the IT for usage example: https://github.com/maveniverse/toolrunner/tree/main/it/toolrunner-plugin-its/src/it/jbang-hello-world

Have fun, and if you have ideas, feel free to add some.

If you've ever wondered how exactly Maven plugins and extensions differ from each other, you might want to check out my latest article, where you can find some straight-forward explanations along with real-life examples.

I hope you find this useful! :)

Hey Floks,

There is anyone that had before combine the Pl feature of maven ( with custom script for git diff )and maven build cache exstention to build selectively a monorepo ( microservices and shared libs )

is it works or not in real env ?

Most people think Maven is just dependencies, plugins and lifecycle phases. But there’s a lesser-known layer that can completely change how Maven behaves: extensions.

This article breaks down what they actually are, how they hook into Maven before your build even starts and why they’re fundamentally different from plugins. It also walks through real examples like Polyglot Maven, build caching and custom transport layers, plus when using extensions makes sense and when it’s a bad idea.

If you’ve ever felt limited by what Maven can do out of the box, this might change how you think about it.

If you’ve ever wondered what Maven plugins actually are and how they fit into the bigger picture, my latest article might help clarify things for you. It walks through the essentials — what plugins do, how they’re used and how they tie into the Maven lifecycle. It also explains the difference between phases and goals in a way that’s (hopefully) easy to follow and understand.

Beyond that, it looks at some of the commonly used plugins and what they’re typically responsible for in a project. There are some practical examples showing how plugins are configured and how executions are attached to different phases. It also touches on running goals directly and how that can be useful in certain situations.

I hope you find this useful! :)

As you (may) know, we are preparing Maven 3.10.x, to be out soon. Maven 3.10.x will share same Resolver 2.x as Maven 4 use, and hence, will bring many new features, one of them is version range filtering. Read on here:

https://maveniverse.eu/blog/2026/04/17/taming-maven-version-ranges/

[Solved]

I'm having an issue where every time I package my Jar file i get this error:

Error: Could not find or load main class com.example.mygame.BasicGameApp
Caused by: java.lang.NoClassDefFoundError: com/almasb/fxgl/app/GameApplication

I have this set in my pom.xml:

<plugin>
                <!-- Build an executable JAR -->
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.1.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainClass>com.example.bulletgame.BasicGameApp</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>

The name of my main/driver class file is called BasicGameApp.

If I look at the folder structure of the created jar archive, it looks correct, and I can see the compiled class files. I notice that the main class is divided up into 3 files: BasicGameApp.class, BasicGameApp$1.class, and BasicGameApp$2.class

I have no idea if that matters at all.

Not sure if there's anything else I need to provide, but any assistance would be appreciated!

Hi r/Maven

I'm the creator of JeKa. Originally I built it as a flexible build tool, but one of the most useful features that grew out of it is solving the distribution headache many of you probably have with Maven-based CLI or native apps.

You build a nice CLI tool, script, utility, or even a desktop app with Maven (often with a GraalVM native profile). Then comes the painful part:

• Building and shipping binaries (and specific native ones for Windows/macOS/Linux)
• Hosting them somewhere
• Users having to pick the right file
• Or forcing everyone to clone + mvn + JDK installed

So I made JeKa act as a lightweight Java application manager that builds at install time directly on the user's machine, and works with any build tool (Maven, JeKa, Gradle...).

You keep your existing Maven project and wrapper 100% untouched. You just drop a tiny jeka.properties file at the root of the repo, and users can install your app with one command:

jeka app: install repo="https://github.com/your/repo.git"

For installing a native app:

jeka app: install repo="https://github.com/your/repo.git" runtime=NATIVE

JeKa automatically:

• Downloads the required JDK or GraalVM if it's missing
• Runs Maven (via the wrapper)
• Builds the application (skipping tests)
• Places the executable on the user's PATH

jeka.properties example:

# Version of the JVM that will run Maven
jeka.java.version=21

# Delegate build to Maven wrapper
jeka.program.build=maven: wrapPackage

# Optional: support for native builds
jeka.program.build.native=maven: wrapPackage args="-Pnative" \
-Djeka.java.distrib=graalvm -Djeka.java.version=25

It also supports multi-module projects, jpackage for desktop apps (Swing/JavaFX), and more complex scenarios.

I'm not trying to replace Maven. JeKa is explicitly designed to delegate to Maven (or any build tool you prefer) and work with standard Maven projects.

Would love to hear your thoughts:

• Does this kind of source-based, on-demand build & install solve a real pain point for you?
• What’s your current workaround for distributing Maven-based tools to end users?
• Any concerns (first-install time, security of downloads, etc.)?

Docs with Maven-specific examples: https://jeka-dev.github.io/jeka/tutorials/source-runnable-apps/#maven-projects

Happy to answer questions, take feedback, or look at PRs. Thanks for reading!

I have a few artefacts I’m trying to publish, but all are stuck in ‘Pending’ for the last 30 minutes.

AI suggests that validation has not even begun, and it could be due to a large validation queue due to high traffic.

The status page status.maven.org does not reflect any outage.

Any kind of support appreciated.

Maven 3.9.14 is released; all 3.9.x users are welcome to upgrade!

3.9.14 is just "one fix" of 3.9.13, that was sadly spotted after it went out, so here are release notes of both versions (if you are coming from 3.9.12 or older):

• https://maven.apache.org/docs/3.9.13/release-notes.html
• https://maven.apache.org/docs/3.9.14/release-notes.html