jira-importer commented on issue #156:
URL: 
https://github.com/apache/maven-jar-plugin/issues/156#issuecomment-2956674141

   **[b. 
ohnsorg](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=b.ohnsorg)**
 commented
   
   maven-jar-plugin uses 
[MavenArchiver](https://github.com/apache/maven-archiver). MavenArchiver 
depends on [Plexus 
Archiver](https://github.com/codehaus-plexus/plexus-archiver). PlexusArchiver 
uses java.util.spi.ToolProvider. Instead 
https://cwiki.apache.org/confluence/display/MAVENOLD/Toolchains suggests 
(omitted some checks for brevity):
   
   ```
   /**
    * @component
    */
   private ToolchainManager toolchainManager;
    
   /**
    * The current build session instance. This is used for
    * toolchain manager API calls.
    *
    * @parameter expression="${session}"
    * @required
    * @readonly
    */
   private MavenSession session;
    
   public void execute() {
       .....
    
       // get toolchain from context
       Toolchain tc = toolchainManager.getToolchainFromBuildContext( "jdk", 
//NOI18N
                               session );
       javadocExecutable = tc.findTool( "javadoc" ); //NOI18N
   }
   ```
   
   I assume that none of the Plexus-provided archivers supports toolchains by 
any means. This is either not a simple patch to maven-jar-plugin since it 
requires replacement of manifest generation. Or it spans across all the 
projects mentioned to put ToolchainManager down the stream.
   
   I am a bit puzzled about the usage of MavenArchiver in maven-jar-plugin. It 
really seems necessary to invoke MavenArchiver.setArchiver to inject a 
JarArchiver…borrowed from injected map of Archiver-instances. This could be 
empty or not contain key-value-pairs for "jar" resp. "mjar". It seems a bit 
pointless to have flexible injection of an interface realized by different 
providers while using hard coded strings and casts to specific classes. Isn't 
this leaky abstraction?
   
   Instead from maven-jar-plugin point of view I'd expect MavenArchiver to be 
ready to use without the need to know how creating/ updating JARs works under 
the hood. In addition the correct signature for the constructor of 
MavenArchiver should be Supplier\<JarArchiver>. (MavenArchiver seems to throw 
NPE in case setArchiver is not invoked. Unless there is some convention that 
injects/ sets archiver.)
   
   No matter how there should be an either-or type picking either classic 
Plexus way or wrapping Toolchain's jar command into something that JarArchiver 
can control. Luckily JarArchiver extends direct ZIP management (of the JDK/ JRE 
that runs Maven). Now I'm quite sure why nobody dared to put toolchain support 
into Plexus archiver or provide it as a sidechain.
   
   https://github.com/codehaus-plexus/plexus-archiver/issues/238
   


-- 
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]

Reply via email to