[
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 9: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 finalname 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 also the file name of the
artifact but this one is created following finalname information
(finalname.type) and is in memory.
But the main problem to retrieve finalname information is that we don't have
anywhere this information, we have to resolve it by analysing the
artifactId-version.pom that can be found in the repository, and searching from
himself and his parents what is the finalname of the artifact.
We will probably need to have maven providing us a easier way to get the full
name such as adding it in the pom.properties.
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.
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.
> 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
