gnodet commented on PR #618: URL: https://github.com/apache/maven-jar-plugin/pull/618#issuecomment-6247143785
@hboutemy — good question, and it's worth clarifying the scope and intent here. This PR is intentionally scoped to `maven-jar-plugin` only. The `ManifestBuilder` and `ArchiveConfiguration` classes are **package-private** — this was an explicit design decision agreed with @desruisseaux (see earlier discussion) to avoid committing to a public API before the design is settled. For other plugins using `MavenArchiver` (`maven-war-plugin`, `maven-source-plugin`, etc.): 1. **No change in this PR** — they continue to use `maven-archiver` as before. This PR doesn't break anything for them. 2. **Long-term path**: if the Maven community wants a shared replacement for `maven-archiver`, the right home would likely be a new `maven-archiver` shared component (or a successor) that wraps the Maven 4 API natively — not `maven-jar-plugin` as a dependency (that would be a layering inversion: a plugin depending on another plugin as a library is unusual and problematic for classloading/lifecycle reasons). 3. **Short-term**: the inlined implementation here can serve as a reference / proof-of-concept for what a Maven 4-native archiver would look like. Once the design is proven stable, extracting it into a shared component would be the natural next step. Making `maven-jar-plugin` a dependency of `maven-war-plugin` is technically possible but I'd consider it the wrong direction — plugins shouldn't depend on each other as libraries, and it would couple release cycles unnecessarily. Does that address your concern, or are you suggesting we should extract a shared component as part of this PR itself? -- 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]
