Hi everyone, I'd like to proceed with adding the capabilities discussed in this thread.
There is a PR in place for review: https://github.com/apache/maven-dependency-plugin/pull/1599 Thanks --- Bruno Borges On Tue, Mar 31, 2026 at 4:34 PM Romain Manni-Bucau <[email protected]> wrote: > > /!\ Doesnt mean dont do the PR, take it more as a step back for your use > case more than your tech solution: > -> give a try to create your own CLI with completion and shorter syntax > (npm install is a good example, not sure anyone uses it but npm i when > coding on the CLI), doesn't have to be maven plugin IMHO > --> can be well integrated to something like mvx ( > https://gnodet.github.io/mvx/) which has custom command (kind of alias) > support even for maven > -> dependency:add already exists: mvn > org.openrewrite.maven:rewrite-maven-plugin:6.35.0:runNoFork > -Drewrite.activeRecipes=org.openrewrite.maven.AddDependency > -Drewrite.options=groupId=org.apache.johnzon,artifactId=johnzon-core,version=2.0.2 > > 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 à 21:54, Bruno Borges <[email protected]> a > écrit : > > > The XML-first vs CLI-first distinction is a fair observation, but I'd > > argue that's exactly the gap worth bridging. Users trigger Maven > > builds from the command-line, not from the XML. Maven being XML-first > > doesn't mean it has to be XML-only. Adding a CLI entry point through a > > plugin that is well known, to perform a common operation doesn't > > change the core paradigm. The pom.xml remains the source of truth, the > > goal just provides a more convenient and reliable way to modify it. > > The same way git config lets you set values without hand-editing > > .gitconfig, even though Git is file-first. > > > > On the verbosity concern, I agree, and that's why the shorthand GAV > > notation was in the original proposal as well as simpler property > > names. For example: > > > > $ mvn dependency:add -Dgav=com.google.adk:google-adk:1.0.0 > > > > For scope, type, and other optional parameters, reasonable defaults > > keep the common case simple. Adding a test-scoped dependency would be: > > > > $ mvn dependency:add -Dgav=com.google.adk:google-adk:1.0.0 -Dscope=test > > > > That's not much worse than npm install --save-dev, and the verbose > > edge cases (annotation processors, managed dependencies) are by > > definition less frequent. > > > > Regarding plugins, that's a good question. There's a reasonable > > argument that dependency:add belongs in the dependency plugin since it > > deals with dependencies, and a separate plugin:add (or similar) could > > live in a different plugin. But there's also a case for a broader "pom > > patcher" plugin as you imply, if the scope expands to cover plugins, > > properties, or other POM sections. I'd prefer to start narrow with > > just dependencies to prove the value, and let the scope grow > > organically from there. Happy to hear what others think on the naming > > and scoping. > > --- > > Bruno Borges > > > > On Tue, Mar 31, 2026 at 2:59 PM Romain Manni-Bucau > > <[email protected]> wrote: > > > > > > There is a big diff you silence between build tools/dep managers you > > > référence and maven: maven is xml first where as most of others are CLI > > > first (several are not even really readable - hashes etc, must be > > > generated). > > > This is likely why it failed and we never got this request seriously. > > > > > > So yes it doesn't hurt but the problem you are trying to solve is not > > there > > > and you solve it changing a core paradigm. > > > > > > Doesn't mean it is bad but not assumed it will be bad so trying to > > > highlight it. > > > > > > Note it has some opportunities Tamas can love like enforced client > > > routing+validating/hashing (lock file like) in a more natural flow...but > > > totally the opposite of what we do promote, document, design so requires > > > some core mindset change. > > > > > > Now once again we have goals way less used than these ones so no problem > > to > > > add them, m'y main issue is to not solve the problem you aim at coding > > for > > > (human side and agent side are both missed in terms of solution IMHO). > > > > > > Also the verbosity of the CLI can need some hack, mvn dependency:add > > > -Ddependency.coordinates=g:a:v -Ddependency.scope=test > > > -Ddependency.type=annotation-processor > > > -Ddependency.useDependencyManagement=true -Ddependency.repository=.... > > > > > > Another question: where will you do the same for plugins? Not sure > > > dependency plugin scope is right, sounds more like a new plugin (pom > > > patcher or alike), no? > > > > > > 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, 19:49, Tamás Cservenák <[email protected]> a > > écrit : > > > > > > > Selecting a version is not hard. > > > > > > > > HOW to add it to POM is. > > > > > > > > For example, current algorithm just to "set version of plugin" (input: > > > > GAV w/ V being the new version): > > > > - look for project/build/plugins GA > > > > - if found, and has version element and is literal (not a property) -> > > > > overwrite -> DONE > > > > - if found, and has version element and is a property -> set property > > > > to V (this branches again to search properties, if found, overwrite -> > > > > DONE) > > > > - if found and have no version, repeat search for > > > > project/build/pluginManagement/plugins (similar like above) > > > > - etc > > > > > > > > Basically you can try the logic by doing: > > > > `mvn toolbox:versions -Dapply` <- it will look for updates, and will > > > > edit the POM. You just need to review and commit. > > > > > > > > > > https://maveniverse.eu/docs/toolbox/plugin-documentation/versions-mojo.html > > > > > > > > By def, it will skip major updates. If you want latest, use > > > > -DartifactVersionSelectorSpec="last()" > > > > > > > > But my problem is that this **does not always work as expected**. > > > > Very much depends on how "clean" is the starting POM. > > > > It always works for me (maveniverse or most ASF Maven projects) but I > > > > did find some POMs that failed... > > > > > > > > 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> > > > > > >>>>> <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] > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
