Maven WAR Plugin
  1. Maven WAR Plugin
  2. MWAR-240

archiveClasses and attachClasses in 2.1

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
      Java version: 1.6.0_18
      Default locale: de_DE, platform encoding: Cp1252
      OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
    • Number of attachments :
      3

      Description

      There seems to be a regression between 2.1-beta-1 and 2.1 with regard to archiveClasses and attachClasses options.

      My use case:
      I have a WAR project with Java classes and I am setting both archiveClasses and attachClasses to true.
      With 2.1-beta-1 it was working correctly (mvn clean install) --> I got classes packaged into a JAR and placed into WEB-INF/lib and I got that JAR artifact deployed to my Maven repository.

      Just upgraded to 2.1 and I got the following with the same use case: I got classes packaged into a JAR and placed into WEB-INF/lib (correct) and I got an empty JAR artifact (only META-INF/ present) deployed to my Maven repository (incorrect).

      Looking at the code in 2.1 of WarMojo (line 230) I am seeing that the classes folder (for classes to be included into attached artifact) is empty, because it was cleared before due to archiveClasses=true

      Trying to debug both code branches I am seeing a difference between 2.1-beta-1 and 2.1 in that the
      getJarArchiver().getDirs() before the call to packager.packageClasses() method (line 233/234)

      is empty in the 2.1:
      (java.util.HashMap<K,V>) {}

      whereas it is not in 2.1-beta-1. It contains a list of all my classes, perhaps because the same archiver instance was used to package them into JAR for WEB-INF/lib.
      That is why I am getting all my classes in the attached artifact with 2.1-beta-1

      I would really need your help in understanding the "correct" behaviour.
      Is this a regression bug for 2.1 or I am completely wrong in my expectations about archiveClasses and attachClasses used together?

      Kind regards
      Sergiy Shyrkov

      1. effective-pom.out
        7 kB
        Sergiy Shyrkov
      2. mwar-240.patch
        2 kB
        Sergiy Shyrkov

        Activity

        Hide
        Dennis Lundberg added a comment -

        Can you please put together a small test project that we can use to test this issue?

        Show
        Dennis Lundberg added a comment - Can you please put together a small test project that we can use to test this issue?
        Hide
        Sergiy Shyrkov added a comment -

        Hello Dennis,

        thanks for the prompt reply!

        I have attached a simple WAR project http://jira.codehaus.org/secure/attachment/51790/mwar-240-test-case.zip that has a single (dummy) Java class, uses maven-war-plugin 2.1 and has both archiveClasses and attachClasses set to "true".
        I have also attached the output of the "mvn help:effective-pom" as http://jira.codehaus.org/secure/attachment/51791/effective-pom.out

        I am running the "mvn clean install" and getting mwar-240-test-case-1.0-classes.jar without any classes (only META-INF).

        When I explicitly set the version of used maven-war-plugin to 2.1-beta-1 in my pom.xml, the packaging works correctly.

        Thank you in advance!

        Kind regards
        Sergiy Shyrkov

        Show
        Sergiy Shyrkov added a comment - Hello Dennis, thanks for the prompt reply! I have attached a simple WAR project http://jira.codehaus.org/secure/attachment/51790/mwar-240-test-case.zip that has a single (dummy) Java class, uses maven-war-plugin 2.1 and has both archiveClasses and attachClasses set to "true". I have also attached the output of the "mvn help:effective-pom" as http://jira.codehaus.org/secure/attachment/51791/effective-pom.out I am running the "mvn clean install" and getting mwar-240-test-case-1.0-classes.jar without any classes (only META-INF). When I explicitly set the version of used maven-war-plugin to 2.1-beta-1 in my pom.xml, the packaging works correctly. Thank you in advance! Kind regards Sergiy Shyrkov
        Hide
        Eric Olander added a comment -

        I see the same problem using Maven 3.0.1 and maven-war-plugin 2.1.1

        Show
        Eric Olander added a comment - I see the same problem using Maven 3.0.1 and maven-war-plugin 2.1.1
        Hide
        Fred Hauschel added a comment -

        Same problem!

        maven-war-plugin:2.1.1
        Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
        Java version: 1.6.0_21
        Default locale: de_DE, platform encoding: Cp1252
        OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

        "org.apache.maven.plugins:maven-war-plugin:2.1-beta-1" works fine!

        Show
        Fred Hauschel added a comment - Same problem! maven-war-plugin:2.1.1 Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200) Java version: 1.6.0_21 Default locale: de_DE, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" "org.apache.maven.plugins:maven-war-plugin:2.1-beta-1" works fine!
        Hide
        Sergiy Shyrkov added a comment -

        Confirm, same issue with Maven 3 and maven-war-plugin 2.1.1 on Windows.

        Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
        Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
        Default locale: de_DE, platform encoding: Cp1252
        OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

        Show
        Sergiy Shyrkov added a comment - Confirm, same issue with Maven 3 and maven-war-plugin 2.1.1 on Windows. Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
        Hide
        Myron added a comment -

        Since this is already annoying (me) for about a year - can someone at least enlighten this question?!

        I would really need your help in understanding the "correct" behaviour.
        Is this a regression bug for 2.1 or I am completely wrong in my expectations about archiveClasses and attachClasses used together?

        Show
        Myron added a comment - Since this is already annoying (me) for about a year - can someone at least enlighten this question?! I would really need your help in understanding the "correct" behaviour. Is this a regression bug for 2.1 or I am completely wrong in my expectations about archiveClasses and attachClasses used together?
        Hide
        Liya Katz added a comment -

        same problem with maven 3.0.3 and war-plugin 2.1.1
        had to downgrade to 2.1-beta-1

        Show
        Liya Katz added a comment - same problem with maven 3.0.3 and war-plugin 2.1.1 had to downgrade to 2.1-beta-1
        Hide
        Sergiy Shyrkov added a comment -

        Hello,

        I've attached a patch (http://jira.codehaus.org/secure/attachment/57596/mwar-240.patch ) against maven-war-plugin version 2.1.1 (but it also applies on the current trunk) that solved the issue for us.

        Kind regards

        Show
        Sergiy Shyrkov added a comment - Hello, I've attached a patch ( http://jira.codehaus.org/secure/attachment/57596/mwar-240.patch ) against maven-war-plugin version 2.1.1 (but it also applies on the current trunk) that solved the issue for us. Kind regards
        Hide
        Arnaud Heritier added a comment -

        Will be fixed in the next version (applied patch + added an integration test)

        Show
        Arnaud Heritier added a comment - Will be fixed in the next version (applied patch + added an integration test)

          People

          • Assignee:
            Arnaud Heritier
            Reporter:
            Sergiy Shyrkov
          • Votes:
            5 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 45 minutes
              45m