Howdy, I did toying with these, for example using mvn CLI: https://asciinema.org/a/FwOS5zFukeARmtKxw7JPdDRVd
or the new mvnsh of mvn4: https://asciinema.org/a/whtVYQBbVVpFRsq0ISJBbw4lr Also, there is MCP of Toolbox too: https://github.com/maveniverse/toolbox/tree/main/mcp Feel free to toy or use these as inspiration. Or just create issues and or PRs. T On Tue, Mar 31, 2026 at 7:32 PM Björn Raupach <[email protected]> wrote: > > From a Maven user perspective: > > mvn dependency:add g:a[:v] would be nice. > > I don’t even care about the version. Just use the latest one. > > I would use these goals a lot and just because I am used to copy and paste > dependencies from websites to my pom.xml doesn’t mean I am happy with that > approach. Yes, I work with Maven from the command line. > > I would the goals to junior developers. They already have a hard time > understanding Maven - even for the easiest things - and they want basic > operations because they see them in tooling from other programming languages. > > I do not care about Agents. > > > > On 31. Mar 2026, at 18:22, Bruno Borges <[email protected]> wrote: > > > > Hi Romain, > > > > I appreciate the perspective from someone who's seen previous attempts > > come and go. > > > > I think there's an important distinction worth drawing, though: JBoss > > Forge and Spring CLI were ambitious, full-featured scaffolding and > > project management tools. They failed not because "adding a dependency > > from the CLI" was the wrong idea, but because they tried to do far too > > much and became their own ecosystems to learn and maintain. What I'm > > proposing is much narrower: three Mojos in an existing, > > well-established plugin. There's no new tool to install, no new > > workflow to adopt. It's just mvn dependency:add, the same way we > > already run mvn dependency:tree. > > > > On the agent cost point, I think we're looking at it from different > > angles. The cost isn't in running Maven (you're right, that's local > > and cheap). The cost is in what the agent has to do before it runs > > anything: read the pom.xml, understand its structure, figure out where > > <dependencies> ends, check whether the dependency already exists, > > decide whether to omit <version> because a parent manages it, handle > > formatting, and write it back without breaking anything. That's a > > non-trivial multi-step operation that the agent has to reason through > > every time, and it's exactly the kind of logic that belongs in a > > plugin in my opinion: deterministic, tested, and reliable. A single > > CLI call replaces all of that reasoning with a guaranteed correct > > outcome. > > > > And this isn't hypothetical. Today, if you ask any AI coding assistant > > to "add Jackson to my Maven project," it will open the pom.xml, try to > > edit the XML, and sometimes get the wrong insertion point, duplicate > > entries, broken formatting and redo. A plugin goal eliminates that > > entire class of errors. > > > > I hear you that this is an old need that's been tried before. But I'd > > argue the context today has changed. The previous attempts failed > > because developers didn't want a new tool, and I agree with that > > instinct. But this isn't a new tool. It's a new goal in a plugin every > > Maven user already has. The bar for adoption is essentially zero while > > the benefits are huge. > > > > I'm not going to pretend this is urgent or blocking anyone. But I do > > think it's a small, well-scoped improvement that makes Maven a little > > more approachable for newcomers, for agent tooling, and for anyone > > who'd rather stay in their terminal. If the community's feeling is > > that it's not worth the maintenance burden, which IMO is very low > > honestly, I respect that. But I'd like to at least hear from more > > members of the Maven Dev team. > > > > Best > > --- > > Bruno Borges > > > > On Tue, Mar 31, 2026 at 11:32 AM Romain Manni-Bucau > > <[email protected]> wrote: > >> > >> Hi Bruno, > >> > >> Well cost should be super low for agents since at the end they must run it > >> locally (othewise no point in any of these tools/cli/commands/mojo) so it > >> should be way more concise than running a verbose maven command (even in > >> log level WARN) so my understanding of your feedback is "agents are bad and > >> no way we make them better" which is not something I think it right so I > >> would fix it at the right level. > >> > >> I'm not sure the "align on others" point should weight at all, once again > >> we got it and it got rejected. > >> Can hear it is a habit thing but using plugins is not beloved while it is > >> that verbose and completion is not that great, indeed you can wire an agent > >> but then you don't need the command anymore too. > >> > >> So overall I don't think we need that for both human and agents - and don't > >> take it as a blocker, more a feedback that this is not a new need, just a > >> very oldish one which failed multiple times. > >> > >> I totally agree agents are not greatly integrated today but the lack of > >> integration is not in maven from the integrations I did or worked with so > >> we should rather fix the cause IMHO. > >> > >> 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 mar. 31 mars 2026 à 17:02, Tamás Cservenák <[email protected]> a > >> écrit : > >> > >>> Howdy, > >>> > >>> Example: > >>> https://gist.github.com/cstamas/416cbae260f7555085f6df3f87f69b85 > >>> > >>> gav - gives an "example" fx current one > >>> artifactVersionMatcherSpec - defines the (sub)range > >>> artifactVersionSelectorSpec - selects the wanted out of the matched > >>> versions list > >>> > >>> But unsure what Romain says, as you cannot talk about "a version" > >>> without stating "version of what". > >>> So unsure what you mean "without a group". > >>> > >>> T > >>> > >>> On Tue, Mar 31, 2026 at 4:45 PM Romain Manni-Bucau > >>> <[email protected]> wrote: > >>>> > >>>> Le mar. 31 mars 2026 à 16:43, Tamás Cservenák <[email protected]> a > >>>> écrit : > >>>> > >>>>> Howdy, > >>>>> > >>>>> unsure why rest api... toolbox fx accepts GA and GAV, and in GA case > >>>>> will use the latest V, discovered "by maven means", basically whatever > >>>>> maven sees will be resolved (in other words Resolver APIs are used). > >>>>> So, whatever your Maven "env is" (Central direct, MRM in settings, > >>>>> etc) and Maven can use, Resolver APIs will work, no need for anything > >>>>> special or proprietary. > >>>>> > >>>> > >>>> No need until you want to leverage more advanced search capabilities and > >>>> optimizations. > >>>> With resolver api it can be hard to search an artifact based on a regex > >>>> without a group to give an example and it is a very relevant search for > >>> an > >>>> agent. > >>>> > >>>> > >>>>> > >>>>> T > >>>>> > >>>>> On Tue, Mar 31, 2026 at 4:34 PM Romain Manni-Bucau > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> there had been several initiatives like that by the past 15 years > >>> (jboss > >>>>>> forge is a well known one, spring has its one as well IIRC to cite > >>> most > >>>>>> well known ones). > >>>>>> ultimately they all fail cause they don't enhance but slow down the > >>>>>> workflow of dev from what I understood > >>>>>> > >>>>>> so ultimately it would be 100% for agents and there nothing is needed > >>>>> since > >>>>>> they can just patch the pom already so I'm not sure it is worth it > >>>>>> (add/remove ones) > >>>>>> > >>>>>> I see some value in search but there too it will ultimately fall > >>> into the > >>>>>> rest api of central + the company repository which can not be > >>> portable > >>>>> and > >>>>>> I'm not sure we do want to support them all > >>>>>> > >>>>>> so overall I'm a bit mixed: > >>>>>> * I agree the intent sounds nice > >>>>>> * technically this is not really needed > >>>>>> * it already fails pre-agent time and agent don't need that > >>>>>> > >>>>>> 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 mar. 31 mars 2026 à 16:27, Tamás Cservenák <[email protected]> > >>> a > >>>>>> écrit : > >>>>>> > >>>>>>> Howdy, > >>>>>>> > >>>>>>> for start check out Toolbox similar goals like > >>>>>>> > >>>>>>> > >>>>> > >>> https://maveniverse.eu/docs/toolbox/plugin-documentation/add-managed-dependency-mojo.html > >>>>>>> > >>>>>>> Also, implementation wise, Xpp3Reader _does not_ preserve > >>> formatting > >>>>>>> nor comments. In fact, this is the sole reason why we did this: > >>>>>>> https://github.com/maveniverse/domtrip > >>>>>>> > >>>>>>> HTH > >>>>>>> T > >>>>>>> > >>>>>>> On Tue, Mar 31, 2026 at 4:01 PM Bruno Borges < > >>> [email protected]> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> I'd like to propose adding three new goals to the Maven > >>> Dependency > >>>>>>>> Plugin: `dependency:add`, `dependency:remove`, and > >>>>>>>> `dependency:search`. I'm volunteering to do the implementation > >>> work > >>>>>>>> and would appreciate feedback on the approach before I begin. > >>>>>>>> > >>>>>>>> Every major dependency management ecosystem provides a simple, > >>>>>>>> single-command way to add a dependency from the command line, > >>> except > >>>>>>>> Maven. Consider how Google's recently released Agent Development > >>> Kit > >>>>>>>> (ADK) documents its installation across languages: > >>>>>>>> > >>>>>>>> * **Python:** `pip install google-adk` > >>>>>>>> * **TypeScript:** `npm install @google/adk` > >>>>>>>> * **Go:** `go get google.golang.org/adk` > >>> <http://google.golang.org/adk> > >>>>> <http://google.golang.org/adk> <http://google.golang.org/adk> > >>>>>>>> * **Java (Maven):** "Open your `pom.xml` and add the following > >>>>>>>> dependency block..." followed by a multi-line XML snippet that > >>> the > >>>>>>>> developer must manually copy, paste, and position correctly. > >>>>>>>> > >>>>>>>> This isn't unique to Google's ADK... it's the same experience for > >>>>>>>> every Java library distributed through Maven Central. While > >>> Cargo has > >>>>>>>> `cargo add`, NuGet has `dotnet add package`, Maven requires > >>>>> developers > >>>>>>>> to leave their terminal, open an XML file, find the right > >>> insertion > >>>>>>>> point, paste a `<dependency>` block, and ensure the formatting is > >>>>>>>> consistent. Even for AI coding agents, calling a CLI would be > >>>>>>>> significantly cheaper (in terms of token usage) than editing an > >>> XML > >>>>>>>> file. This friction is a real barrier, particularly for > >>> developers > >>>>>>>> coming from other ecosystems, and it makes Maven feel dated > >>> compared > >>>>>>>> to its peers. > >>>>>>>> > >>>>>>>> # Proposed goals > >>>>>>>> > >>>>>>>> ## `dependency:add` - Adds a dependency to the project's > >>> `pom.xml`. > >>>>>>>> > >>>>>>>> ``` > >>>>>>>> mvn dependency:add -DgroupId=com.google.adk > >>> -DartifactId=google-adk > >>>>>>>> -Dversion=1.0.0 > >>>>>>>> mvn dependency:add -Dgav="com.google.adk:google-adk:1.0.0" > >>>>>>>> mvn dependency:add -DgroupId=com.google.adk > >>> -DartifactId=google-adk > >>>>>>>> -Dversion=1.0.0 -Dscope=test > >>>>>>>> ``` > >>>>>>>> > >>>>>>>> The goal would parse the existing `pom.xml`, insert the > >>> dependency in > >>>>>>>> the `<dependencies>` section, preserve existing formatting and > >>>>>>>> comments, and write the file back. If the dependency already > >>> exists, > >>>>>>>> it would update the version (or warn, depending on a flag). > >>>>>>>> > >>>>>>>> ### `<dependencies>` vs `<dependencyManagement>` > >>>>>>>> > >>>>>>>> By default, `dependency:add` would insert into the > >>> `<dependencies>` > >>>>>>>> section, since that's the most common use case and the closest > >>> analog > >>>>>>>> to what `npm install` or `cargo add` do. However, a > >>>>>>>> `-DdependencyManagement` flag (or shorter alias `-Dmanaged`) > >>> would > >>>>>>>> target the `<dependencyManagement>` section instead: > >>>>>>>> > >>>>>>>> ``` > >>>>>>>> mvn dependency:add -Dgav="com.google.adk:google-adk:1.0.0" > >>> -Dmanaged > >>>>>>>> ``` > >>>>>>>> > >>>>>>>> When adding to `<dependencyManagement>`, the version is always > >>>>>>>> required. When adding to `<dependencies>` in a child module > >>> where the > >>>>>>>> parent already manages that dependency's version via > >>>>>>>> `<dependencyManagement>`, the version parameter would be > >>> optional — > >>>>>>>> the goal would detect the managed version and omit `<version>` > >>> from > >>>>>>>> the inserted block, following Maven's established convention. > >>>>>>>> > >>>>>>>> ### Multi-module projects > >>>>>>>> > >>>>>>>> In multi-module projects, the behavior depends on where the > >>> command > >>>>> is > >>>>>>> executed: > >>>>>>>> > >>>>>>>> * **From a child module directory:** the dependency is added to > >>> that > >>>>>>>> module's `pom.xml`. This is the default and most intuitive > >>> behavior: > >>>>>>>> you `cd` into the module you want to modify and run the command, > >>> just > >>>>>>>> as you would run `npm install` from a specific package directory > >>> in a > >>>>>>>> monorepo. > >>>>>>>> > >>>>>>>> * **From the root/parent directory with `-Dmanaged`:** the > >>> dependency > >>>>>>>> is added to the parent's `<dependencyManagement>` section, > >>> making the > >>>>>>>> version centrally governed. Child modules can then declare the > >>>>>>>> dependency without specifying a version. > >>>>>>>> > >>>>>>>> * **From the root/parent directory without `-Dmanaged`:** the > >>>>>>>> dependency is added to the parent's `<dependencies>` section, > >>> meaning > >>>>>>>> it will be inherited by all child modules. This is a legitimate > >>> use > >>>>>>>> case (e.g., adding a logging facade or a common utility across > >>> all > >>>>>>>> modules), but since it has broad impact, the goal would print a > >>>>>>>> warning: _"Adding dependency to parent POM — this will be > >>> inherited > >>>>> by > >>>>>>>> all child modules. Use -Dmanaged to add to dependencyManagement > >>>>>>>> instead."_ > >>>>>>>> > >>>>>>>> This goal would also support a `-Dmodule=module-name` parameter > >>> to > >>>>>>>> target a specific child module from the root directory without > >>> having > >>>>>>>> to `cd` into it. > >>>>>>>> > >>>>>>>> ## `dependency:remove` - Removes a dependency from the project's > >>>>>>> `pom.xml`. > >>>>>>>> > >>>>>>>> ``` > >>>>>>>> mvn dependency:remove -DgroupId=com.google.adk > >>>>> -DartifactId=google-adk > >>>>>>>> mvn dependency:remove -Dgav=com.google.adk:google-adk > >>>>>>>> ``` > >>>>>>>> > >>>>>>>> By default, this removes from `<dependencies>`. The `-Dmanaged` > >>> flag > >>>>>>>> would target `<dependencyManagement>` instead. When removing a > >>>>> managed > >>>>>>>> dependency from a parent POM, the goal would warn if any child > >>>>> modules > >>>>>>>> still reference that dependency without an explicit version, > >>> since > >>>>>>>> those modules would break on the next build. > >>>>>>>> > >>>>>>>> ## `dependency:search` - Queries Maven Central for artifacts > >>> matching > >>>>>>>> a search term. > >>>>>>>> > >>>>>>>> ``` > >>>>>>>> mvn dependency:search -Dquery=google-adk > >>>>>>>> ``` > >>>>>>>> > >>>>>>>> This would return a concise list of matching `groupId:artifactId` > >>>>>>>> pairs with their latest versions, making it easy to discover > >>>>>>>> coordinates without leaving the terminal. > >>>>>>>> > >>>>>>>> # What I'm not proposing > >>>>>>>> > >>>>>>>> ## Conflict resolution tooling > >>>>>>>> > >>>>>>>> Automatic resolution of version conflicts is a complex problem > >>> with > >>>>>>>> many edge cases. The existing `dependency:tree` and > >>>>>>>> `dependency:analyze` goals are better starting points for > >>>>>>>> understanding conflicts, and automated resolution would require > >>>>>>>> careful design. This is better left for a separate discussion. > >>> Adding > >>>>>>>> or removing dependencies using the command line achieves the same > >>>>>>>> result as manually editing the XML files; neither prevents > >>> potential > >>>>>>>> conflicts or issues. > >>>>>>>> > >>>>>>>> ## Vulnerability auditing or license checking > >>>>>>>> > >>>>>>>> Plugins like `org.owasp:dependency-check-maven` and > >>>>>>>> `org.codehaus.mojo:license-maven-plugin` already handle these > >>>>> concerns > >>>>>>>> well. Duplicating their functionality here would fragment the > >>>>>>>> ecosystem without adding clear value. > >>>>>>>> > >>>>>>>> ## SBOM generation > >>>>>>>> > >>>>>>>> Both `org.cyclonedx:cyclonedx-maven-plugin` (CycloneDX format) > >>> and > >>>>>>>> `org.spdx:spdx-maven-plugin` (SPDX format) are actively > >>> maintained > >>>>> and > >>>>>>>> closely track their respective evolving specifications. A > >>>>>>>> general-purpose plugin would inevitably lag behind these > >>> dedicated > >>>>>>>> implementations. > >>>>>>>> > >>>>>>>> ## Migration assistance > >>>>>>>> > >>>>>>>> Helping developers navigate breaking changes across major > >>> dependency > >>>>>>>> upgrades requires deep semantic understanding of API changes; the > >>>>> kind > >>>>>>>> of analysis that likely depends on AI/LLM tooling rather than a > >>> build > >>>>>>>> plugin. This is an interesting space but outside the scope of > >>> what > >>>>> the > >>>>>>>> dependency plugin should tackle in my opinion. > >>>>>>>> > >>>>>>>> # Implementation notes > >>>>>>>> > >>>>>>>> * `pom.xml` modification would use a formatting-preserving XML > >>>>>>>> approach (likely `MavenXpp3Reader`/`Writer` or similar) to avoid > >>>>>>>> reformatting the entire file. > >>>>>>>> * The search goal would use the Maven Central REST API (or Solr > >>>>> search > >>>>>>>> endpoint) by default, with support for custom repository search > >>> if > >>>>> the > >>>>>>>> repository exposes a compatible API. > >>>>>>>> * All goals would respect the standard Maven plugin parameter > >>>>>>>> conventions and work in both single-module and multi-module > >>> projects. > >>>>>>>> * For multi-module projects, the goals would resolve the > >>> effective > >>>>> POM > >>>>>>>> to determine whether a dependency version is already managed by a > >>>>>>>> parent, and adjust the inserted XML accordingly (omitting > >>> `<version>` > >>>>>>>> when already managed). > >>>>>>>> > >>>>>>>> I'd welcome any feedback on the scope, naming conventions, or > >>>>>>>> implementation approach. I will start working on it as soon as we > >>>>> have > >>>>>>>> some general agreement that this would be a valuable addition. > >>>>>>>> > >>>>>>>> Best regards > >>>>>>>> --- > >>>>>>>> Bruno Borges > >>>>>>>> > >>>>>>>> > >>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>> For additional commands, e-mail: [email protected] > >>>>>>>> > >>>>>>> > >>>>>>> > >>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: [email protected] > >>>>>>> > >>>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
