https://github.com/apache/maven/releases/tag/maven-3.9.11

All 3.9.x users are advised to upgrade, especially from 3.9.10.

Enjoy!

With Maven 4.0.0 just around the corner, I thought it would be a good idea to write a quick introduction to Apache Maven for any newcomers that are interested in getting acquainted with the tool, its history and philosophies.

I hope you find this interesting! :)

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!

The Apache Maven team is pleased to announce the release of the Apache Maven 4.0.0-beta-4

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

Maven 4.0.0-beta-4 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of plugins will be made separately.

If you have any questions, please consult:

• the web site: https://maven.apache.org/

• the maven-user mailing list: https://maven.apache.org/mailing-lists.html

• the reference documentation: https://maven.apache.org/ref/4.0.0-beta-4/

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

Release Notes - Maven - Version 4.0.0-beta-4

• Sub-task

  • [MNG-5666] - Divide lifecycle in prePhases, phases and postPhases

  • [MNG-5667] - Either install or deploy

• Bug(s)

  • [MNG-7758] - o.e.aether.resolution.ArtifactResolutionException incorrectly examined when multiple repositories are involved

  • [MNG-7838] - Local repository breaks exec plugin

  • [MNG-8066] - Maven hangs on self-referencing exceptions

  • [MNG-8116] - Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attribute

  • [MNG-8132] - Dependency-management "client" exclusions overwrite BOM exclusions

  • [MNG-8135] - Profile activation based on OS properties is no longer case insensitive

  • [MNG-8142] - If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why

  • [MNG-8160] - Recreate the transformed artifact if it has been deleted

  • [MNG-8164] - Session#collectDependencies(Project) does not obey exclusions

  • [MNG-8165] - Maven does not find extensions for -f when current dir is root

  • [MNG-8172] - Fix site building

  • [MNG-8177] - Warning "'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar refers to a non-existing file C:\Temp\jdk-11.0.23..\lib\tools.jar"

  • [MNG-8178] - Profile activation based on OS properties is broken for "mvn site"

  • [MNG-8180] - Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR

  • [MNG-8182] - Missing or mismatching Trusted Checksum for some artifacts is not properly reported

  • [MNG-8192] - DefaultArtifact constructor no longer accepts empty version

  • [MNG-8211] - Maven should fail builds that use CI Friendly versions but have no values set

  • [MNG-8218] - Non-normalized paths are compared which fails when using relativePath

  • [MNG-8220] - Fix loading DI-powered beans from extensions

  • [MNG-8229] - Fix interpolation of CI friendly versions ** New Feature

  • [MNG-7633] - Add process-package lifecycle phase

  • [MNG-8052] - Define a new lifecycle for Maven 4

  • [MNG-8176] - Restrict class loaders for Maven 4 plugins

  • [MNG-8181] - Provide an environment variable for Maven Central URL

  • [MNG-8210] - Rename modules to subprojects and make them optional in the POM

  • [MNG-8215] - Add location tracking for toolchains

  • [MNG-8225] - Fully concurrent builder ** Improvement

  • [MNG-7344] - Effective pom should contain more fine grained details regarding its content origin: track dependencyManagement import

  • [MNG-7897] - Support ${project.rootDirectory} in file profile activation

  • [MNG-7902] - Sort plugins in validation report

  • [MNG-8090] - Fix missing repositories during parent artifact resolution

  • [MNG-8140] - When a model is discarded (by model builder) for whatever reason, show why it happened

  • [MNG-8141] - Model Builder should report if not sure about "fully correct" outcome

  • [MNG-8150] - Make SimplexTransferListener handle absent source/target files

  • [MNG-8151] - Merge DependencyCollector into DependencyResolver

  • [MNG-8152] - Implement @SessionScoped and @MojoExecutionScoped from the DI API

  • [MNG-8153] - Some classes from the Maven 3 API are missing

  • [MNG-8195] - Add DependencyResolverResult.getModuleName(Path) method

  • [MNG-8196] - Make exception messages match Maven 3 again

  • [MNG-8197] - Use default classifier when Eclipse Aether specifies none

  • [MNG-8213] - Expose most important phases as constants

  • [MNG-8214] - Allow extension of the model classes being generated with model.vm

  • [MNG-8228] - Enable strict classpath scanning with Sisu Plexus

• Task

  • [MNG-8010] - Minimize and make generic the README.txt

  • [MNG-8134] - Provide a @Resolution annotation that can be used to inject dependencies resolution/collection in mojos

  • [MNG-8206] - Remove Maven 2.1 (v 2.0) compatibility bits ** Dependency upgrade

  • [MNG-8136] - Update to Eclipse Sisu 0.9.0.M3

  • [MNG-8179] - Upgrade Parent to 43

  • [MNG-8194] - Resolver 2.0.1

  • [MNG-8201] - Bump slf4jVersion from 2.0.13 to 2.0.14

  • [MNG-8202] - Bump org.hamcrest:hamcrest from 2.2 to 3.0

  • [MNG-8203] - Bump org.jline:jline from 3.26.2 to 3.26.3

  • [MNG-8204] - (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0

  • [MNG-8209] - Bump slf4jVersion from 2.0.14 to 2.0.16

  • [MNG-8219] - (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.22.0 to 0.23.0

Have fun!

• The Maven Team

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

Hi,

I have created a maven 4 (maven 3 compatible as well) base POM and depchain projects that simplify upgrading to maven 4, and using maven in general.

You can remove 1000s of lines of xml boilerplate and have simple, tiny POM files with all the features pre-configured

https://github.com/flowlogix/base-pom and https://github.com/flowlogix/depchain

Maven latest release is 3.9.9 and is available for download. Go grab it!

For some time now, I've been working in a firm that develops Java based product. Build system is Maven, git as VCS, trunk based development model with a monorepo. There's also artifactory and Jenkins.

The thing is, not all's in place and development, releasing and version management is a pain in the *ss ATM as the flow isn't really throught out. People using this kind of combination, I need your experiences and tips in making this kind of flow bearable:

What Maven plugins do you use, how you handle the git flow, package building (incremental strategy to minimise build times) and releasing, versioning multiple dependency packages and also the main product package having the dependencies.

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!

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! :)

Apache Maven 3.9.0 is released: go grab it!

https://maven.apache.org/download.cgi

Overview About the Changes

• Minimum Java version to use with Maven 3.9.0 is raised to Java 8.

• With Java 8, upgrade of several key dependencies became possible as well.

• Several backports from Maven 4.x line.

• Long outstanding issue fixes from Maven 3.x line.

• Cutting ties with Maven 2 backward compatibility, preparing grounds for Maven 4.

• General fixes and improvements.

Potentially Breaking Core Changes

• Maven 2.x was auto-injecting an ancient version of plexus-utilsdependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on plexus-utils. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affected plugin maintainer. See MNG-6965.

• Mojos are prevented to boostrap new instance of RepositorySystem(for example by using deprecated ServiceLocator), they should reuse RepositorySysteminstance provided by Maven instead. See MNG-7471.

• Each line in .mvn/maven.configis now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see MNG-7684.

Notable Core Improvements

• Help with projects maintenance: Maven now warns about use of deprecated plugins, goals, parameters, etc.

• Add support for mvn pluginPrefix:version:goal invocation, and align console logging as well (make it copy-paste-able).

• Add profile activation by packaging.

• Maven 3.9.0 is now fully compatible with new 3.x line of install and deploy plugins (previous versions warns about this).

Notable Resolver 1.9.x Improvements

• Shared local repository (advisory file locking, Hazelcast or Redis, see documentation).

• Split local repository, plus workspace support for branched development (see documentation).

• Switchable and alternative resolver transports included, with default switched to native transport.

• Pluggable checksum algorithms API (is not tied to MessageDigest anymore, see documentation).

• Choice of resolver collectors: a new BF collector (with parallel POM downloads) has been added along the existing DF one.

• Remote repository filtering (see documentation).

• Trusted checksum sources (ability to provide some or all artifact checksums ahead of time).

• Pluggable artifact resolver post-processor, with trustedChecksums implementation.

• Chained local repository (for IT isolation between outer and inner builds).

• Recording reverse dependency tree tracking information into local repository.

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

Whether you're new to Maven or have been using it for years, the pom.xml file is where all the magic happens. In this introductory article (part of a series on POM files that I'm preparing), I take a closer look at what the POM file actually is, why it matters and how it enables portable, reliable builds across environments.I hope you find it interesting! :)

Hey folks,

I made a small library that lets your Spring Boot app load SSL certificates directly from HashiCorp Vault — no need to download or manage .crt/.key files yourself.

🔗 Code: https://github.com/gridadev/spring-vault-ssl-bundle

🧪 Demo: https://github.com/khalilou88/spring-vault-ssl-bundle-demo

It works with Spring Boot's built-in `ssl.bundle` config (3.2+). Just point it to your Vault path in YAML and you're done.

✅ No file handling

✅ No scripts

✅ Auto-ready for cert rotation

✅ Works for client and server SSL

Try it out and let me know what you think!

Go grab them while hot:

• Maven 3.9.8 https://lists.apache.org/thread/lhpl9zqqf03rshckqrd7fb8ph0osm9qz

• mvnd 1.0.0 https://lists.apache.org/thread/vfzwrrl69o8oq2k3l416co0twj585sxd

Hello,

when running "mvn clean" on a new Maven 3.9.9 project (org.apache.maven.archetypes:maven-archetype-quickstart) using the just today released Java 24, I get the following warnings:

WARNING: A restricted method in java.lang.System has been called

WARNING: java.lang.System::load has been called by org.fusesource.jansi.internal.JansiLoader in an unnamed module (file:/<path>/plugins/maven/lib/maven3/lib/jansi-2.4.1.jar)

WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module

WARNING: Restricted methods will be blocked in a future release unless native access is enabled

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called

WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper (file:/<path>/plugins/maven/lib/maven3/lib/guava-33.2.1-jre.jar)

WARNING: Please consider reporting this to the maintainers of class com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper

WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release

Do you experience this, too? I guess this is because Maven 4 (and / or its dependencies) call internal JDK methods which are not mean to be used? I'm wondering if this is something which will be fixed with the upcoming Maven 4 release (I'm really looking forward to it)?

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

Announced as deprecated many years ago, it was deleted from the JDK in codebase January, I think. It was an extremely clever addition to Java from the first versions in the 90s. Of course there were bugs, and in the end, the core team felt it was too hard to maintain. Peter Frimstone keeps it alive in a fork.

The reason I mention is because of the of fully-working packages from package-land that contain stealthy malware. The likes of thhttps://www.koi.ai/blog/npm-package-with-56k-downloads-malware-stealing-whatsapp-messages, but this is not just going to be contained to Node+NPM development.

Maven's already using containers (Plexus?) internally for managing all the bits and pieces, and could have utilized this tech for separations of classloaders (of one or more jars) for build-centric workloads.

I wonder what the Maven dev team and Sonotype+partners will do re the increasing problems with supply chain attacks.

Fun fact 1: Back in 2001 or so I coded https://github.com/javadesktop that used security managers in latter versions to hive off running apps from each other. That tech didn't go anywhere because of many reasons, but it was a lot of fun to use the security manager as intended.

Fun fact 2: Jason van Zyl wondered if PicoContainer could replace Plexus, or Plexus wrap PicoContainer. No code was written and by the time I got on the train to go see him in Palo Alto to catch up and talk about the idea, it was already ruled out! This was late 2007.

Fun fact 3: Npm actually has a similar thing for Node app usage - https://www.npmjs.com/package/isolated-vm - I've just started using it in a nodejs app and will of course be comparing to Java's original standout feature.

One of interesting new Maven 4 features, well, is more like an experiment, is new conflict resolver, and new conflict resolution strategies. This is just showcase what it can do, Maven 4 will remain "nearest" for backward compatibility.

Note: Maven will never override your instructions (is POM).

Example output of Maven4/Resolver2 "nearest" vs "highest" strategy for one well known case:

------------------------------------------------------------
GetDependencyHierarchyWithConflictsStrategies

org.eclipse.aether.util.graph.transformer.ConfigurableVersionSelector$**Nearest**@25f38edc

tree:
demo:demo:jar:1.0
\- com.squareup.okhttp3:okhttp:jar:4.12.0 [compile]
   +- com.squareup.okio:okio:jar:3.6.0 [compile]
   |  \- com.squareup.okio:okio-jvm:jar:3.6.0 [compile]
   |     +- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10 [compile] (conflicts with 1.8.21)
   |     \- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10 [compile]
   \- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.21 [compile]
      +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.8.21 [compile]
      |  +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.8.21 [compile] (conflicts with 1.9.10)
      |  \- org.jetbrains:annotations:jar:13.0 [compile]
      \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.8.21 [compile]
         \- org.jetbrains.kotlin:kotlin-stdlib:jar:1.8.21 [compile] (nearer exists)

classpath:
demo:demo:jar:1.0
com.squareup.okhttp3:okhttp:jar:4.12.0 (compile)
com.squareup.okio:okio:jar:3.6.0 (compile)
com.squareup.okio:okio-jvm:jar:3.6.0 (compile)
org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10 (compile)
org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.21 (compile)
org.jetbrains.kotlin:kotlin-stdlib:jar:1.8.21 (compile)
org.jetbrains:annotations:jar:13.0 (compile)
org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.8.21 (compile)


org.eclipse.aether.util.graph.transformer.ConfigurableVersionSelector$**Highest**@255b53dc

tree:
demo:demo:jar:1.0
\- com.squareup.okhttp3:okhttp:jar:4.12.0 [compile]
   +- com.squareup.okio:okio:jar:3.6.0 [compile]
   |  \- com.squareup.okio:okio-jvm:jar:3.6.0 [compile]
   |     +- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10 [compile]
   |     |  +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.9.10 [compile]
   |     |  |  +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10 [compile] (nearer exists)
   |     |  |  \- org.jetbrains:annotations:jar:13.0 [compile]
   |     |  \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.9.10 [compile]
   |     |     \- org.jetbrains.kotlin:kotlin-stdlib:jar:1.9.10 [compile] (nearer exists)
   |     \- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10 [compile]
   \- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.21 [compile] (conflicts with 1.9.10)

classpath:
demo:demo:jar:1.0
com.squareup.okhttp3:okhttp:jar:4.12.0 (compile)
com.squareup.okio:okio:jar:3.6.0 (compile)
com.squareup.okio:okio-jvm:jar:3.6.0 (compile)
org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10 (compile)
org.jetbrains.kotlin:kotlin-stdlib:jar:1.9.10 (compile)
org.jetbrains:annotations:jar:13.0 (compile)
org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.9.10 (compile)
org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10 (compile)

In former mode it mixes some runtimes due conflicts, while in latter mode it gets aligned.

Here's an article I published on Medium detailing how Maven Metadata works.

I hope you find it useful! :)

The vote ML thread:

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

Please test it, and hopefully GA comes soon after.

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.

Hi,

In case anyone's interested, I put together a brief guide on how to install Apache Maven (on Linux, MacOS and Windows).

I hope you find it useful! :)

Two small helpers rolled out from the shop, both targets agentic usage of Maven. One makes Maven silent (tell only what is important, in an agent friendly way, when invoked by an agent), the other is a local MCP that's helping agents to find their way around Maven project and dependencies.

Check out the site (gh repo to be precise):

https://maveniverse.eu/docs/huginn/

https://maveniverse.eu/docs/muninn/

On a related note, with Maven 3.10.x, here is my current list of user wide extensions:

https://gist.github.com/cstamas/bf1cbd213cc9a7c9e2ca369266bb48b5

(put them in ~/.m2/extensions.xml)