Maven 2 & 3

Cannot specify additional classpath entries in manifest when using addClasspath

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4
  • Fix Version/s: 2.0.5
  • Component/s: None
  • Labels:
    None
  • Environment:
    Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP
  • Complexity:
    Intermediate
  • Number of attachments :
    2

Description

When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41

I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Perham added a comment -

Anyone have any comments on this? Is it a good idea to allow people to futz with their Class-Path? And if so, is it a good idea to hardcode the check for Class-Path in maven-archiver as the patch does? I'm not sure how I feel about this one...

Show
Mike Perham added a comment - Anyone have any comments on this? Is it a good idea to allow people to futz with their Class-Path? And if so, is it a good idea to hardcode the check for Class-Path in maven-archiver as the patch does? I'm not sure how I feel about this one...
Hide
Permalink
Brett Porter added a comment -

I think this is ok. Basically, this gives 4 scenarios:

  • no classpath
  • just the default (addClasspath > true)
  • just the hand coded one (Class-Path in entries)
  • additive default + extras (addClassPath > true & Class-Path entries)

There aren't any other fields where an additive default makes sense.

Show
Brett Porter added a comment - I think this is ok. Basically, this gives 4 scenarios:
  • no classpath
  • just the default (addClasspath > true)
  • just the hand coded one (Class-Path in entries)
  • additive default + extras (addClassPath > true & Class-Path entries)
There aren't any other fields where an additive default makes sense.
Hide
Permalink
Mike Perham added a comment -

Patch applied with small tweaks (the user supplied value should come first so its resources can come first in the classpath and override resources in the standard jars). maven-archiver is no longer part of Maven, proper, so the fix version is irrelevant. It is fixed in maven-archiver 2.1 which will be part of the maven-jar-plugin 2.1 release.

Show
Mike Perham added a comment - Patch applied with small tweaks (the user supplied value should come first so its resources can come first in the classpath and override resources in the standard jars). maven-archiver is no longer part of Maven, proper, so the fix version is irrelevant. It is fixed in maven-archiver 2.1 which will be part of the maven-jar-plugin 2.1 release.
Hide
Permalink
Fredrik Vraalsen added a comment -

Hi,

I'm still having problems with this, but of a different sort now. If I have a configuration such as the following:

<manifest>
<addClasspath>true</addClasspath>
</manifest>
<manifestEntries>
<Class-Path>resources/</Class-Path>
</manifestEntries>

I now get the following in my manifest.mf:

Class-Path: resources/
Class-Path: resources/

In other words, still two Class-Path entries in the manifest file, only this time they both have the value 'resources/', and the classpath created by addClasspath is gone. This is with latest maven-jar-plugin 2.1-SNAPSHOT (maven-archiver 2.1).

I'm trying to create a JUnit test-case for maven-archiver, but I'm still trying to work out the details of how to set this up. In the meanwhile, I'll attach a simple stand-alone pom file which shows the problem.

Show
Fredrik Vraalsen added a comment - Hi, I'm still having problems with this, but of a different sort now. If I have a configuration such as the following: <manifest> <addClasspath>true</addClasspath> </manifest> <manifestEntries> <Class-Path>resources/</Class-Path> </manifestEntries> I now get the following in my manifest.mf: Class-Path: resources/ Class-Path: resources/ In other words, still two Class-Path entries in the manifest file, only this time they both have the value 'resources/', and the classpath created by addClasspath is gone. This is with latest maven-jar-plugin 2.1-SNAPSHOT (maven-archiver 2.1). I'm trying to create a JUnit test-case for maven-archiver, but I'm still trying to work out the details of how to set this up. In the meanwhile, I'll attach a simple stand-alone pom file which shows the problem.
Hide
Permalink
Fredrik Vraalsen added a comment -

see previous comment

Show
Fredrik Vraalsen added a comment - see previous comment
Hide
Permalink
Fredrik Vraalsen added a comment -

Simple stand-alone test pom which shows the problem with two Class-Path entries.

Show
Fredrik Vraalsen added a comment - Simple stand-alone test pom which shows the problem with two Class-Path entries.
Hide
Permalink
Fredrik Vraalsen added a comment -

The user-defined manifest entries are added to the manifest in the public getManifest method as well as the createArchive method. Since createArchive calls getManifest, the entries end up getting added twice.

This patch removes the code which adds the entries in createArchive, in addition to the previous fix for addClasspath vs. user-defined Class-Path issue.

Show
Fredrik Vraalsen added a comment - The user-defined manifest entries are added to the manifest in the public getManifest method as well as the createArchive method. Since createArchive calls getManifest, the entries end up getting added twice. This patch removes the code which adds the entries in createArchive, in addition to the previous fix for addClasspath vs. user-defined Class-Path issue.
Hide
Permalink
Brett Porter added a comment -

applied

Show
Brett Porter added a comment - applied

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.