[
https://jira.codehaus.org/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322310#comment-322310
]
Hesham Saleh edited comment on MASSEMBLY-450 at 3/21/13 6:18 AM:
-----------------------------------------------------------------
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.". Which is a bit strange, why would a supplied file have more
precedence than supplied configuration ?)
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).
was (Author: heshamsl65):
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
