brunoborges commented on PR #1599: URL: https://github.com/apache/maven-dependency-plugin/pull/1599#issuecomment-4184781527
### Design note: why `DependencyEntry` instead of existing classes We evaluated replacing `DependencyEntry` with classes already on the classpath: | Class | GAV parsing | `g:a` (no version) | scope/optional | Verdict | |---|---|---|---|---| | `DefaultArtifact` (Aether) | ✅ `g:a[:ext[:cls]]:v` | ❌ Throws | ❌ | Cannot replace parser | | `Dependency` (maven-model) | ❌ No parser | N/A | ✅ | Cannot replace parser | | `DependencyEntry` (ours) | ✅ | ✅ | ✅ | Keeps both | **Key constraint:** `dependency:remove` legitimately accepts `g:a` without a version (it matches by groupId:artifactId only). `DefaultArtifact` throws `IllegalArgumentException` on 2-token inputs because its format requires `<groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>` — version is mandatory. Using `DefaultArtifact` would require a fallback wrapper for the 2-token case, and using `Dependency` as a carrier would scatter scope validation and `toString()` logic across both mojos. The net effect would be ~80 fewer lines but worse cohesion. **Decision:** Keep `DependencyEntry` as a focused value object (~228 lines) that bridges GAV parsing + scope validation + all dependency fields in one place. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
