You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Martin Desruisseaux (JIRA)" <ji...@codehaus.org> on 2006/10/25 19:38:01 UTC
[jira] Created: (MJAR-61) Manifest classpath ignores the "real" JAR
filenames specified in
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
[jira] Commented: (MJAR-61) Manifest classpath ignores the "real"
JAR filenames specified in
Posted by "Daniel Green (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188671#action_188671 ]
Daniel Green commented on MJAR-61:
----------------------------------
Thank you Darbois for the information. Is there a current workaround to this issue?
> 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
[jira] Commented: (MJAR-61) Manifest classpath ignores the "real"
JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136490#action_136490 ]
darbois tomas commented on MJAR-61:
-----------------------------------
The problem on Maven Jar plugin is still existing. maven Jar plugin is currently on version 2.2
Does anyone have an update on the problem ? Or a patch /workaround :p
Thanks
> 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
[jira] (MJAR-61) Manifest classpath ignores the "real" JAR
filenames specified in
Posted by "Peter Coder (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MJAR-61) Manifest classpath ignores the "real"
JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136648#action_136648 ]
darbois tomas commented on MJAR-61:
-----------------------------------
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
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
[jira] Issue Comment Edited: (MJAR-61) Manifest classpath ignores
the "real" JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ 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 11:32 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 final name such as adding it in the pom.properties.
A possible solution is to do the same work than help:effective-pom : Load the pom associated with the artifact, parse it (the same way effective pom is doing it) and just recover the final name.
Perhaps some tools in maven-model would be usefull in that case instead of parsing everything :p
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 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.
> 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
[jira] Updated: (MJAR-61) Manifest classpath ignores the "real" JAR
filenames specified in
Posted by "Markku Saarela (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markku Saarela updated MJAR-61:
-------------------------------
Attachment: MJAR-61.zip
Install common-jar first and then multi-module project.I also created MSHARED-147 issue for this one, because it's Maven Archiver issue.
> 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
> 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 contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAR-61) Manifest classpath ignores the "real" JAR
filenames specified in
Posted by "Peter Coder (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305031#comment-305031 ]
Peter Coder edited comment on MJAR-61 at 7/31/12 12:41 AM:
-----------------------------------------------------------
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:
{code}${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}{code}
.. 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>
<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.
was (Author: petercoder):
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
[jira] Issue Comment Edited: (MJAR-61) Manifest classpath ignores
the "real" JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ 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:10 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.
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
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
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
[jira] Commented: (MJAR-61) Manifest classpath ignores the "real"
JAR filenames specified in
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196448#action_196448 ]
Dennis Lundberg commented on MJAR-61:
-------------------------------------
Can somebody provide a sample project that highlights this issue?
> 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
[jira] Issue Comment Edited: (MJAR-61) Manifest classpath ignores
the "real" JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Issue Comment Edited: (MJAR-61) Manifest classpath ignores
the "real" JAR filenames specified in
Posted by "darbois tomas (JIRA)" <ji...@codehaus.org>.
[ 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