[ https://jira.codehaus.org/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322310#comment-322310 ]
Hesham Saleh commented on MASSEMBLY-450: ---------------------------------------- After some tracking, maven-jar-plugin depends on maven-archiver, which uses plexus-archiver internally to build archives. I found the following lines in plexus-archiver:JarArchiver.java:createManifest: {code} JdkManifestFactory.merge( finalManifest, filesetManifest, false ); JdkManifestFactory.merge( finalManifest, configuredManifest, false ); JdkManifestFactory.merge( finalManifest, manifest, !mergeManifestsMain ); {code} These lines seem the responsible for the issue in hand, however, there is a comment prceeding this block which declares that "Precedence: manifestFile wins over inline manifest, over manifests read from the filesets over the original manifest.". To cut a long debugging story shorter on anyone who intends to dig through this, here are some facts: - The original MANIFEST file is represented by the variable _manifest_ in the above code - Any additional parameters supplied through manifestEntries entry in the POM, is set at _configuredManifest_ (This happens by maven-archiver:MavenArchiver.java:createArchive) - The POM's XML configuration (manifestEntries and manifestFile) are binded by the maven-jar-plugin to an object of MavenArchiveConfiguration, this config object is supplied "as is" to the previously mentioned maven-archiver:MavenArchiver.java:createArchive method. I was successfully able to reach the desired results by a small change in maven-archiver shown in the following patch: {code} hesham@hesham-work-laptop ~/dev/maven $ cat diff-maven-archiver Index: src/main/java/org/apache/maven/archiver/MavenArchiver.java =================================================================== --- src/main/java/org/apache/maven/archiver/MavenArchiver.java (revision 1458914) +++ src/main/java/org/apache/maven/archiver/MavenArchiver.java (working copy) @@ -20,6 +20,7 @@ */ import java.io.File; +import java.io.FileReader; import java.io.IOException; import java.util.ArrayList; import java.util.Collections; @@ -546,7 +547,7 @@ if ( manifestFile != null ) { - archiver.setManifest( manifestFile ); + archiver.addConfiguredManifest(new Manifest(new FileReader(manifestFile))); } Manifest manifest = getManifest( session, workingProject, archiveConfiguration ); {code} However, considering I am new to the code base I feel this is a bit hackish, I will try to dig more into things to figure out more formal way. BTW, a small issue brings itself: MANIFEST's Bundle-Version should conform to the OSGi specs, this will need manipulating the version declared in the POM to be compatible with OSGi's MANIFEST. (i.e. POM's 1.0.0-RC1-SNAPSHOT would turn something like 1.0.0.RC1-SNAPSHOT). > manifestEntries ignored when manfestFile is specified > ----------------------------------------------------- > > Key: MASSEMBLY-450 > URL: https://jira.codehaus.org/browse/MASSEMBLY-450 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: manifest > Affects Versions: 2.2-beta-4 > Reporter: Robert Cauble > Attachments: example.zip > > > The maven jar plugin supports the behavior of manifestEntries overriding the > manifestFile as indicated here: > http://maven.apache.org/guides/mini/guide-manifest.html > However, within the maven assembly plugin, if manifestFile is specified, > manifestEntries is ignored. > Reproduction > ============ > {noformat} > > unzip example.zip > > cd example > > mvn package > > cd target > > unzip example-4.2-plugin.jar > > cat META-INF/MANFEST > {noformat} > Results: > {noformat} > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: 14.0-b16 (Sun Microsystems Inc.) > Bundle-ManifestVersion: 2 > Bundle-Name: example > Bundle-SymbolicName: example; singleton:=true > Bundle-Version: 1.0 > {noformat} > Expected: > {noformat} > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: 14.0-b16 (Sun Microsystems Inc.) > Bundle-ManifestVersion: 2 > Bundle-Name: example > Bundle-SymbolicName: example; singleton:=true > Bundle-Version: 4.2 > {noformat} > The problem appears to be in the class ManifestConfigurationFinalizer: > {code:java} > if ( manifestFile != null ) > { > ... > manifest = new Manifest( manifestFileReader ); > ... > } > else > { > manifest = mavenArchiver.getManifest( project, > archiveConfiguration.getManifest() ); > } > {code} > I believe the fix is to change to the following (this already handles merging > the manifest file with the configured manifestEntries) > {code:java} > manifest = mavenArchiver.getManifest( project, archiveConfiguration ); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira