[
https://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305031#comment-305031
]
Peter Coder commented on MJAR-61:
---------------------------------
I don't have a fix for this - there is a workaround though.
Version 2.4 of the Maven archiver (maven-archiver) uses by default a different
approach to generating the classpath vs version 2.2.
maven-archiver version 2.2: uses artifact file name
maven-archiver version 2.4: uses a pattern that looks a bit like this:
${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
.. which would give a classpath entry like this: TheJarFile-3.4-SNAPSHOT.jar
(N.B. maven-archiver version 2.2 is used by e.g. maven-ejb-plugin 2.1;
maven-archiver 2.4 is used by e.g. maven-ejb-plugin 2.2 and 2.3)
The easiest way to construct your classpath entries using the
<build><finalName> is to use the following configuration:
{code}
<plugin>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<ejbVersion>3.0</ejbVersion>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathLayoutType>custom</classpathLayoutType>
<customClasspathLayout>$${artifact.file.name}</customClasspathLayout>
</manifest>
</archive>
</configuration>
</plugin>
{code}
The workaround for maven-jar-plugin and maven-war-plugin is the same.
> Manifest classpath ignores the "real" JAR filenames specified in <finalName>
> ----------------------------------------------------------------------------
>
> Key: MJAR-61
> URL: https://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Martin Desruisseaux
> Attachments: MJAR-61.zip
>
>
> The manifest classpath generated by Maven ignores the "real" JAR name as
> specified in {{<finalName>}}. For example the Geotools project tried the
> following configuration:
> {code:xml}
> <build>
> <finalName>gt-${artifactId}-${version}</finalName>
> {code}
> but the manifest classpath generated by Maven contains only
> {{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
> *Note:* this problem happen only when the JAR dependencis come from the
> repository. The manifest classpath is correct if all dependencies were
> compiled in the same "{{mvn install}}" cycle. However this workaround is
> applicable only to Geotools developpers (in our case), because users of the
> Geotools library usually download the dependencies from a repository.
> This bug may be related to MJAR-28.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
