[
http://jira.codehaus.org/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202030#action_202030
]
Mirko Raner commented on MASSEMBLY-450:
---------------------------------------
I'm struggling with the same issue. I have an existing MANIFEST.MF file with a
dummy version number, and I'd like to use the actual Maven build version in the
final manifest instead:
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>META-INF/MANIFEST.MF</manifestFile>
<manifestEntries>
<Bundle-Version>${version}</Bundle-Version>
</manifestEntries>
</archive>
</configuration>
I'm not entirely convinced that it was a good choice to have the presence of a
<manifestFile> element override other directives, such as <manifestEntries>. I
think that intuitively most developers would expect both elements to be honored
and the entries to be merged in a reasonable way. Changing this behavior would
obviously break existing POMs out there that rely on the
<manifestFile>-overrides-<manifestEntries> semantics, though I would venture
that the presence of both elements in a POM very likely indicates that indeed
the contents of both elements were desired in the final manifest.
If changing the behavior is not an option I suggest to introduce another
element that allows the user to specify a merge behavior instead of an override
behavior.
> manifestEntries ignored when manfestFile is specified
> -----------------------------------------------------
>
> Key: MASSEMBLY-450
> URL: http://jira.codehaus.org/browse/MASSEMBLY-450
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> 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
> ============
> > unzip example.zip
> > cd example
> > mvn package
> > cd target
> > unzip example-4.2-plugin.jar
> > cat META-INF/MANFEST
> Results:
> 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
> Expected:
> 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
> The problem appears to be in the class ManifestConfigurationFinalizer:
> if ( manifestFile != null )
> {
> ...
> manifest = new Manifest( manifestFileReader );
> ...
> }
> else
> {
> manifest = mavenArchiver.getManifest( project,
> archiveConfiguration.getManifest() );
> }
> I believe the fix is to change to the following (this already handles merging
> the manifest file with the configured manifestEntries)
> manifest = mavenArchiver.getManifest( project, archiveConfiguration );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
