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] >
smime.p7s
Description: S/MIME cryptographic signature
