Maven 1.x War Plugin
  1. Maven 1.x War Plugin
  2. MPWAR-33

Plugin generates multiple Class-Path entries in the manifest file

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6
    • Fix Version/s: 1.6.1
    • Labels:
      None
    • Number of attachments :
      1

      Description

      Hi,
      Running war:war (maven-war-plugin-1.6) the first time generates a manifest file with a single Class-Path entry (correctly including the
      dependencies), but running war:war a second time (with no clean-up done) generates multiple Class-Path entries.

      This problem does not occure when building the EJB's (maven-ejb-plugin-1.4). When I compared theese two I noticed that the war-plugin does an update while the ejb-plugin does not. By removing the update attribute the war-plugin works fine, for me anyway

      I have the same problem with 1.7-SNAPSHOT from CVS-HEAD.

      Since my project includes other developers and users I would like to avoid making (local) changes in the plugin. Currently the solution is to do a clean-up in the pre-goal to war:war.

      Cheers
      Joran

      [manifest after first run]

      Manifest-Version: 1.0
      Ant-Version: Apache Ant 1.5.3
      Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.)
      Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar
      Built-By: Joran

      Name: foo.bar
      Specification-Title: foo-web
      Specification-Version: 1.0
      Specification-Vendor: Apache Software Foundation
      Implementation-Title: foo.bar
      Implementation-Version: 1.0
      Implementation-Vendor: Apache Software Foundation

      [manifest after second run]

      Manifest-Version: 1.0
      Ant-Version: Apache Ant 1.5.3
      Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.)
      Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar
      Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar
      Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar
      Built-By: Joran

      Name: foo.bar
      Specification-Title: foo-web
      Specification-Version: 1.0
      Specification-Vendor: Apache Software Foundation
      Implementation-Title: foo.bar
      Implementation-Version: 1.0
      Implementation-Vendor: Apache Software Foundation

      [a snippet from project.xml]

      <dependency>
      <groupId>jena</groupId>
      <artifactId>icu4j</artifactId>
      <jar>icu4j.jar</jar>
      <properties>

      <war.manifest.classpath>true</war.manifest.classpath>
      </properties>
      </dependency>

      1. test.rar
        17 kB
        Jöran Stark

        Activity

        Hide
        Felipe Leme added a comment -

        Joran,

        Could you please write a simple test-case for this issue (i.e., a simple project.xml whose consecutive calls to maven war:war generates the invalid war)? I've tried to reproduce it, but the error didn't happens...

        Anyway, I think the fix is essy, it's just a matter of removing the 'update=true' attribute from <ant:jar>:

        <ant:jar
        destfile="$

        {maven.war.build.dir}

        /$

        {maven.war.final.name}

        "
        basedir="$

        {maven.war.webapp.dir}

        "
        update="true"
        index="$

        {maven.war.index}

        ">

        – Felipe

        Show
        Felipe Leme added a comment - Joran, Could you please write a simple test-case for this issue (i.e., a simple project.xml whose consecutive calls to maven war:war generates the invalid war)? I've tried to reproduce it, but the error didn't happens... Anyway, I think the fix is essy, it's just a matter of removing the 'update=true' attribute from <ant:jar>: <ant:jar destfile="$ {maven.war.build.dir} /$ {maven.war.final.name} " basedir="$ {maven.war.webapp.dir} " update="true" index="$ {maven.war.index} "> – Felipe
        Hide
        Jöran Stark added a comment -

        A simple example project.

        Show
        Jöran Stark added a comment - A simple example project.
        Hide
        Jöran Stark added a comment -

        I have attached a project that generates a faulty war-file.

        To re-produce the problem
        =========================
        1. Run maven genapp
        2. Add a dependency and includ it in the Class-Path

        <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.8</version>
        <properties>
        <war.manifest.classpath>true</war.manifest.classpath>
        </properties>
        </dependency>

        3. Run maven war:war
        4. Modify and save the Java-file (only so that the project is re-built).
        5. Run maven war:war again.

        The new war-file contains duplicated Class-Path entries (my faulty war-file is included in the attached file)

        – Jöran

        Show
        Jöran Stark added a comment - I have attached a project that generates a faulty war-file. To re-produce the problem ========================= 1. Run maven genapp 2. Add a dependency and includ it in the Class-Path <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.8</version> <properties> <war.manifest.classpath>true</war.manifest.classpath> </properties> </dependency> 3. Run maven war:war 4. Modify and save the Java-file (only so that the project is re-built). 5. Run maven war:war again. The new war-file contains duplicated Class-Path entries (my faulty war-file is included in the attached file) – Jöran
        Hide
        Felipe Leme added a comment -

        Turns out I couldn't reproduce it because I wasn't updating a source file
        Anyway, I fixed by removing the update=true attribute from <ant:jar> call.

        Show
        Felipe Leme added a comment - Turns out I couldn't reproduce it because I wasn't updating a source file Anyway, I fixed by removing the update=true attribute from <ant:jar> call.
        Hide
        Arnaud Heritier added a comment -

        I'm not sure that it is a good idea to remove the update attribute, because if your application server uses this war (during the dev), I'm not sure that you can replace it.
        I'll try to test it the next week.

        Show
        Arnaud Heritier added a comment - I'm not sure that it is a good idea to remove the update attribute, because if your application server uses this war (during the dev), I'm not sure that you can replace it. I'll try to test it the next week.
        Hide
        Felipe Leme added a comment -

        Arnaud,

        I was wondering if the update=true was there for some reason (as all other plugins like jar, ear, rar and ejb didn't set it), now I got the answer

        Anyway, if that's the case, it's just a matter of adding a new property (something like maven.war.update), which by default should be false (that would break backward compatibility, but I think the expected behaviour is always to create a fresh archive).

        – Felipe

        PS: again, I think it's important for the archive plugins (jar, war, ejb, ear, etc..) to be consistent, so if we add this property here we should add it to the others as well

        Show
        Felipe Leme added a comment - Arnaud, I was wondering if the update=true was there for some reason (as all other plugins like jar, ear, rar and ejb didn't set it), now I got the answer Anyway, if that's the case, it's just a matter of adding a new property (something like maven.war.update), which by default should be false (that would break backward compatibility, but I think the expected behaviour is always to create a fresh archive). – Felipe PS: again, I think it's important for the archive plugins (jar, war, ejb, ear, etc..) to be consistent, so if we add this property here we should add it to the others as well

          People

          • Assignee:
            Felipe Leme
            Reporter:
            Jöran Stark
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: