Manifest classpath ignores the "real" JAR filenames specified in <finalName>

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

Thanks

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

Thank you Darbois for the information. Is there a current workaround to this issue?

Can somebody provide a sample project that highlights this issue?

Install common-jar first and then multi-module project.I also created MSHARED-147 issue for this one, because it's Maven Archiver issue.

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:

<plugin>
	<artifactId>maven-ejb-plugin</artifactId>
	<configuration>
		<archive>
			<manifest>
				<addClasspath>true</addClasspath>
				<classpathLayoutType>custom</classpathLayoutType>
				<customClasspathLayout>$${artifact.file.name}</customClasspathLayout>
			</manifest>
		</archive>                                                                                             
	</configuration>
</plugin>

The workaround for maven-jar-plugin and maven-war-plugin is the same.