Maven JAR Plugin
  1. Maven JAR Plugin
  2. MJAR-29

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

            • Assignee:
              Unassigned
              Reporter:
              Michael Böckling
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: