Maven 2.x JAR Plugin

Artifact name not correctly calculated for EAR

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    maven 2.0.2
    maven-jar-plugin-2.1-SNAPSHOT
  • Number of attachments :
    0

Description

In a parent POM, I added jar:sign to the plugins section, thus adding it to the default lifecycle. In a child, I try to build an EAR.
Problem:

  • It tries to sign a <artifactId><version>.jar instead of <artifactId><version>.ear, thus resulting in an error.
  • Should jar:sign really trigger on an EAR artifact at all?

Error message:

[INFO] [jar:sign {execution: jar.sign}]
[INFO] jarsigner: unable to open jar file: C:\Dokumente und Einstellungen\mbo\wo
rkspace\BAL-DruckComponentServer-Ear\target\druck-component-server-ear-0.9-SNAPS
HOT.jar
[INFO] -------------------------------------------------------------------------

[ERROR] BUILD ERROR
[INFO] -------------------------------------------------------------------------

[INFO] Result of C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe -keystor
e "C:\Dokumente und Einstellungen\mbo/.keystore" -storepass Giniality -keypass G
iniality -signedjar "C:\Dokumente und Einstellungen\mbo\workspace\BAL-DruckCompo
nentServer-Ear\target\signed\druck-component-server-ear-0.9-SNAPSHOT.jar" "C:\Do
kumente und Einstellungen\mbo\workspace\BAL-DruckComponentServer-Ear\target\druc
k-component-server-ear-0.9-SNAPSHOT.jar" mykey execution is: '1'.

Issue Links

Activity

Hide
Brett Porter added a comment -

This is a bit tricky. You are telling Maven to run that goal every time. Presumably to save space by including a portion of that in each subproject (the configuration could still be shared via pluginManagement).

We could make jar:sign a no-op if packaging != jar - but is that correct? are there other packagings that still produce a jar and should be signable?

Show
Brett Porter added a comment - This is a bit tricky. You are telling Maven to run that goal every time. Presumably to save space by including a portion of that in each subproject (the configuration could still be shared via pluginManagement). We could make jar:sign a no-op if packaging != jar - but is that correct? are there other packagings that still produce a jar and should be signable?
Hide
Michael Böckling added a comment -

That is the big question. I do not have enough experience to judge whether or not Wars, Ears, Sars, Rars and whatnot can / should be signed. I can workaround this problem for now by manually specifiying the path to the artifact in the child pom, but htis is of course not optimal.
What I would like to see is a possibility to disable an execution inherited from a parent, something like "<inherited/>" from the childs point of view.

Show
Michael Böckling added a comment - That is the big question. I do not have enough experience to judge whether or not Wars, Ears, Sars, Rars and whatnot can / should be signed. I can workaround this problem for now by manually specifiying the path to the artifact in the child pom, but htis is of course not optimal. What I would like to see is a possibility to disable an execution inherited from a parent, something like "<inherited/>" from the childs point of view.
Hide
Jerome Lacoste added a comment -

See also MJAR-27 for not signing pom packaged projects.

Show
Jerome Lacoste added a comment - See also MJAR-27 for not signing pom packaged projects.
Hide
Corridor Software Developer added a comment -

I'm currently facing a case where the jar:sign is not signing an ejb-client jar file for me. I need this to occur so I many use it in a webstart app, but webstart don't support ejb-client files apparently. The workaround for me is to use the dependency plugin to move the ejb-client jar into place first; however, webstart doesn't sign it anyway so I need to sign it in advance.

working on a patch now.

Show
Corridor Software Developer added a comment - I'm currently facing a case where the jar:sign is not signing an ejb-client jar file for me. I need this to occur so I many use it in a webstart app, but webstart don't support ejb-client files apparently. The workaround for me is to use the dependency plugin to move the ejb-client jar into place first; however, webstart doesn't sign it anyway so I need to sign it in advance. working on a patch now.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: