[
http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136648#action_136648
]
darboist edited comment on MJAR-61 at 5/29/08 6:14 AM:
------------------------------------------------------------
I've taken a look at the origin of the problem :
maven jar plugin is using maven Archiver which is using the function
getManifest( MavenProject project, ManifestConfiguration config, Map entries )
in order to create the manifest.
In case he is using the repository to resolve the dependency :
Inside this program, mavenArchiver get the list of file.getpath from the
repository so it's something like GroupId/Version/ArtifactId-Version.type and
he resolve the name by a getname on the path = artifactid-version.type
So he will never look inside the artifact and check if the fullname is not the
same as the repositoryname.
Perhaps it's an error to use fullname that doesn't look like
artifactid-version.type
in case he doesn't need the repository he is using the fullname parameter.
was (Author: darboist):
I've taken a look at the origin of the problem :
maven jar plugin is using maven Archiver which is using the function
getManifest( MavenProject project, ManifestConfiguration config, Map entries )
in order to create the manifest.
Inside this program, mavenArchiver get the list of file.getpath from the
repository so it's something like GroupId/Version/ArtifactId-Version.type and
he resolve the name by a getname on the path = artifactid-version.type
So he will never look inside the artifact and check if the fullname is not the
same as the repositoryname.
Perhaps it's an error to use fullname that doesn't look like
artifactid-version.type
> Manifest classpath ignores the "real" JAR filenames specified in <finalName>
> ----------------------------------------------------------------------------
>
> Key: MJAR-61
> URL: http://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Martin Desruisseaux
>
> 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 contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
