Add dependency:add, dependency:remove and dependency:search goals using DomTrip

[gnodet]

Summary

Alternative approach to #1599 — thin mojos leveraging DomTrip for lossless POM editing and jakarta.json for search API parsing.

• dependency:add — adds/updates a dependency, preserving formatting, comments, and whitespace. Supports -Dgav, -Dmanaged, -Dscope, -DuseProperty, -DpropertyName, -Dalign.
• dependency:remove — removes a dependency (regular or managed).
• dependency:search — searches Maven Central via the Sonatype Central Search API. Non-interactive tabular output.

Convention auto-detection (align=true, the default)

When adding a dependency, the mojo analyzes existing dependencies to automatically follow the project's patterns:

• Managed dependencies: If most existing deps are version-less (delegated to <dependencyManagement>), the new dep is added the same way
• Version properties: If existing versions use property references (${...}), a property is created following the detected naming convention
• Property naming: Detects .version (e.g. guava.version), -version (e.g. guava-version, Camel-style), Version (camelCase), and version. prefix conventions
• Multi-module: Walks the parent POM chain to find the POM with <dependencyManagement>, adds the managed dep + property there, and adds a version-less dep to the child POM

Explicit flags (-Dmanaged, -DuseProperty, -DpropertyName, -Dalign=false) override auto-detected conventions.

Usage examples

# Add a dependency (auto-detects conventions)
mvn dependency:add -Dgav=com.google.guava:guava:33.0.0-jre

# Add with explicit scope
mvn dependency:add -Dgav=com.google.guava:guava:33.0.0-jre -Dscope=test

# Add with explicit managed dep and property
mvn dependency:add -Dgav=org.junit:junit-bom:5.11.0 -Dmanaged -DpropertyName=junit.version

# Disable convention detection
mvn dependency:add -Dgav=com.google.guava:guava:33.0.0-jre -Dalign=false

# Remove a dependency
mvn dependency:remove -Dgav=commons-io:commons-io

# Search Maven Central
mvn dependency:search -Dquery=guava -Drows=10

Dependencies added

• eu.maveniverse.maven.domtrip:domtrip-maven:0.6.0 (EPL-2.0, ASF Cat-B — already accepted in Maven 4 core)
• org.glassfish:jakarta.json:2.0.1 promoted from test to compile scope (already in the project)

Test plan

• 13 integration tests covering all goals and convention detection scenarios
  • Basic add/remove, managed deps, properties, scopes
  • Multi-module with .version convention
  • Multi-module with -version convention (Camel-style)
  • Remove not-found (expected failure)
  • Search Maven Central
• CI build passes
• Manual testing in real projects (tested in Apache Camel)

🤖 Generated with Claude Code

Claude Code on behalf of Guillaume Nodet

[brunoborges]

@gnodet is domtrip being used already by any other Maven Plugin? And what's the rationale for adding new dependencies to 3.x plugins?

[gnodet]

@gnodet is domtrip being used already by any other Maven Plugin? And what's the rationale for adding new dependencies to 3.x plugins?

Not yet used by other plugins at the moment afaik. It will probably come over time. There was some discussion for the release-plugin which was stalled because DomTrip was really new at that time. All the plugins that modify POMs are usually a pain because they can loose lots of stuff from the POMs and cause big diffs in the resulting XML, even though both are semantically equivalent (spaces in attributes, quotes, comments before the document element, etc...). Domtrip is really 100% roundtrip safe.

Adding new dependencies is not really a problem per se, we just need to do that wisely. In that very case, I'd rather add dependencies to domtrip + a json parser rather than recoding those.

[brunoborges]

@gnodet and what is the license compatibility for using DomTrip in an Apache Licensed maven plugin?