Filename inconsistency between jar in build directory and attached one

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add the onejar-maven-plugin in your build lifecycle
2. Configure it so it attach the produced jar to the build
3. Specify a custom classifier (optionnal)

Example configuration snippet :
    <attachToBuild>true</attachToBuild>
    <classifier>yourcustomclassifier</classifier>

What is the expected output? What do you see instead?

For example a project with artifactId "test" :
 - test-1.0-SNAPSHOT.one-jar.jar in the target/ directory
 - test-1.0-SNAPSHOT-yourcustomclassifier.jar in the maven repository

What version of the product are you using? 

1.4.0

Original issue reported on code.google.com by eskato...@gmail.com on 26 Mar 2009 at 7:56

[GoogleCodeExporter]

Implementation note: Instead of current finalName+".one-jar.jar", use
finalname+"-"+classifier+".jar"

Original comment by hugo.josefson.old@gmail.com on 26 Mar 2009 at 8:01

• Changed state: Accepted
• Added labels: Milestone-Release2.0.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Since fixing this issue will break backwards-compatibility, it will have to be
included in the next major release.

Workaround for versions 1.x.x:

Add this to your plugin configuration:
<filename>${project.build.finalName}-yourcustomclassifier.jar</filename>

<filename> is what the file in target will be called, and <classifier> is for 
the
installed/deployed artifact.

Original comment by hugo.josefson.old@gmail.com on 26 Mar 2009 at 8:04

[GoogleCodeExporter]

If we just use ${project.build.finalName}-yourcustomclassifier.jar as the 
default 
value in the case that <filename> isn't specified, wouldn't that maintain 
backwards 
compatibility and allow us to address the issue immediately?

Original comment by dstov...@gmail.com on 7 Apr 2009 at 11:11

[GoogleCodeExporter]

I am reluctant to change the default behavior of any major version, such as 
version
1. What I mean by backwards compatibility, is that no user should be affected
negatively by a change, if they rely on that version's default behavior.

Maybe that's a bit too cautious. We *could* of course do this change already in 
1.5.0
the way you mention, Drew. We would then say specifically to everyone that 
they'll
have to take an extra look at any external scripts they might have that rely on 
the
default filename, and possibly start using the <filename> tag where appropriate.

What do all you think?

Original comment by hugo.josefson.old@gmail.com on 8 Apr 2009 at 6:32

[GoogleCodeExporter]

Sorry, I did a bad job of cut-n-paste...

I see two options:
1) Add support for a 'filename' parameter,
default value is [${project.build.finalName}.one-jar.jar],
and the resulting filename is [${filename}]

2) Add support for a 'classifier' parameter,
default value is [.one-jar],
and the resulting filename is [${project.build.finalName}${classifier}.jar].

2.1) If need be, version 2.0 can strip any leading '-' characters from 
${classifier} 
and insert a '-' to create a filename of [${project.build.finalName}-
${classifier}.jar]

Original comment by dstov...@gmail.com on 9 Apr 2009 at 1:34

[GoogleCodeExporter]

Issue 9 has been merged into this issue.

Original comment by hugo.josefson.old@gmail.com on 15 Apr 2009 at 8:17

[GoogleCodeExporter]

In response to comment #5...

Option 2) describes the behavior that the current implementation is to supposed 
to
guarantee IMO. In regular builds the $classifier is always added to the default
${project.build.finalName}. The plugin's current implementation actually breaks 
this
convention as far as I understand. So, it's a bug...

However, I don't fully understand this behavior anyway it seems. I ask myself 
why I
would always have two JARs in the target folder, the 
${project.build.finalName}.jar
plus a ${project.build.finalName}.jar.one-jar.jar (if <attachToBuild>false) or
${project.build.finalName}.one-jar.jar (if <attachToBuild>true).
If I use what is described as "Technique B" on
http://onejar-maven-plugin.googlecode.com/svn/mavensite/usage.html I expect to 
have
only 1 single JAR. The negative effect of the current behavior is that when I 
execute
"mvn install" the original JAR ends up in the repo and not the one-jar enabled 
JAR.

Original comment by marcel@frightanic.com on 13 Dec 2009 at 12:53