assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}

This issue is cloned from MASSEMBLY-3

The issue title should read "assembling dependent jars that contain snapshots" not "assembling dependent jars or snapshots".

This is still happening. I have a feeling that the assembly is doing the correct thing while the jar plugin is not, so I'll also open an issue within the jar plugin project and link it to this one.

This seems to occur when snapshot versions have been uploaded to the remote repository. If snapshot versions exist within the local repository then everything works out fine (jars are named version-SNAPSHOT in both plugins).

jar plugin seems to be in the wrong.

However, I'm unsure why you use the jar plugin to write your manifest - shouldn't you add the <archive> section to the assembly plugin?

Brett, could you elaborate please?

I'm not familiar with the archive section of the assembly plugin, but I am not sure how this would work anyway.
(I can't find the archive definition at http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html and there is no information about the archive parameter at the mojo decriptions.)

The jar file needs in META-INF/MANIFEST.MF entries like:

Class-Path: <dep1> <dep2> etc

so that I can just run on the command line:

java -jar <jar file>

So this would be part of the jar plugin.

All the assembly's task is to create the correct directory structure so that the project's jar and all dependencies are copied to the correct locations so that the Class-Path declaration matches the file locations.

Cheers

<archive> is in the configuration element (like it is for a JAR). I think it should also be supported in the assembly descriptor, but that's a separate issue as it isn't right now.

http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html

So, this allows you to write out the archive configuration if the assembly is producing a JAR in the same way as if you were just producing a JAR.

Ok,
I think the problem is that we are not using the archiver to assemble a jar.

We are using the archiver to assemble a binary distribution of the jar, with all dependencies.
Therefore we need the version values in the manifest to match the versions in the binary distribution as well.

I'm not clear if the Class-Path entry should be -SNAPSHOT or the resolved version identifiers.
The only reason for a -SNAPSHOT would be for development purposes and so it would be easier to just use -SNAPSHOT rather than the timestamped snapshot versions.

ok, so you aren't producing a jar in the assembly plugin.

1) you produce a jar with a manifest and main-class and class-path
2) you produce an assembly (say, zip) that contains the above jar, and the elements of the class-path

if this is the case, then this can be closed won't fix as there's nothing wrong with the assembly plugin (the bug is the writing of the incorrect class-path in the jar plugin).

Ok I have thrown together all my notes that I was using while investigating this.
I have also included a patch that has integration test cases that show the desired behaviour. I wouldn't be applying those patches to the SCM, just use them locally.

The error occurs in MavenArchiver at the lines 82-108 in the config.isAddClasspath block.
The problem is that the classpath is configured from
project.getRuntimeClasspathElements()
and appended to the classpath by converting the artifact to a file and use the name part of the file.

For SNAPSHOT files, these will ALWAYS resolve to -SNAPSHOT, even though it is a duplicate copy of the timestamped version.

So it looks like MavenArchiver should be using an algorithm similar to Assembly for creating the Class-Path entry. (The code should be refactored so it can be shared)

However, I could only find MavenArchiver from maven/components/tags/maven-2.0.4
Does that mean to fix this we have to go to Maven 2.0.5?

Woops, I've attached the comments to this bug rather than MJAR-28.
Never mind, they are related.
Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html

I've reposted my request for help as it has been a week and no response from the dev list.

(Well it's not quite a week... but) Anyway I've found a web enabled IRC client and asked on the maven irc channel.
#maven channel on the codehaus IRC server: irc.codehaus.org:6667

The latest code base (I was struggling to find) is at http://svn.apache.org/repos/asf/maven/shared/trunk/maven-archiver

Also the correct place for archiver defects is in http://jira.codehaus.org/browse/MNG using the maven-archiver component.

I have provided refactoring, test cases and a patch to fix this bug on MNG-2456, as it is not really a problem with the assembler.

I think the tight coupling of maven-archiver and assembler means that the use of outputFileNameMapping in dependencySet should be deprecated as these filenames must match.

The solution here is to use an outputFileNameMapping such as this:

$

-$

for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use $

for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.

I've added an integration test: /basic-features/outputFileNameMapping-withArtifactBaseVersion to verify that this is fixed.

Is this supposed to work for current versions of the assembly plugin? I've tried putting an outputFileNameMapping in my dependencySet, but it doesn't seem to make any difference.

Richard: the fix for is 2.2, which is the current SVN version - it is not released.

ah right, thanks. I'll look into rolling my own build of it then...

I wrote up the steps I did to roll my own:
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins

Don't you guys think it is an issue that depending on who did the deploy of the snapshot and who is doing the assembly you will have different results? ie.
I wrote and deployed the snapshot and then do the assembly...dependency jars come out with -SNAPSHOT
One of my developers does the assembly...dependency jars come out with the datestamp.

We now have two flavours of assemblies zips that can wreak havok with predefined classpaths.

It sounds like this is an issue with the deploy plugin itself since it should be consistent no matter who actually did the deploy.

Please see MASSEMBLY-91 for a description of a further problem with jars with classifiers and a workaround that you can use.

I just had problems somewhat related to this issue, but instead I was trying to get all timestamps for my snapshots. I wrote up my findings under another closed jira http://jira.codehaus.org/browse/MASSEMBLY-211?focusedCommentId=259987&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_259987