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> > > > > > * **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]
