gnodet commented on PR #618: URL: https://github.com/apache/maven-jar-plugin/pull/618#issuecomment-6255592958
> everything copied in 1 plugin: and other plugins? at Maven and at wider community https://central.sonatype.com/artifact/org.apache.maven/maven-archiver/dependents ? > > they will copy/paste too code and documentation? what is complex to understand in that topic? maven-jar-plugin is not the only one > > removing plexus-archiver is a good move: removing maven-archiver is not @hboutemy — to make the choice concrete, there are really two paths: **Option 1 — This PR as-is** Inline manifest generation in `maven-jar-plugin`, package-private, no shared API. Other plugins continue using `maven-archiver` + `plexus-archiver` unchanged. When (if) they migrate to Maven 4 API and the `jar` tool, we extract the shared parts then — with full requirements from all plugins in hand. **Option 2 — Trim maven-archiver first** Before merging this PR, create a `maven-archiver` 4.x branch that drops `plexus-archiver` and `MavenArchiver.createArchive()`, keeping only the manifest generation logic (`<archive><manifest>` config + `MANIFEST.MF` building), rewritten against the Maven 4 API. `maven-jar-plugin` depends on that. When other plugins migrate, they extend the same shared component rather than starting from scratch. One important consequence of Option 2: since no other packaging plugin is currently being migrated to Maven 4 API, a trimmed `maven-archiver` 4.x would be manifest-only for the foreseeable future, as we decided to not expand the number of Maven 4 plugins in the near future. Any community plugin currently using `maven-archiver` for archive creation (not just manifest generation) could not upgrade to 4.x without losing that functionality — which is a significant regression for the broader ecosystem. Option 2 addresses your concern about consistency sooner, but at the cost of designing the shared API with only `maven-jar-plugin`'s requirements — before we know what WAR/EAR/EJB will need. That risks locking in the wrong API and having to break it later. Option 1 defers the shared component until we have the full picture. -- 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]
