Uploaded image for project: 'Maven Assembly Plugin'
  1. Maven Assembly Plugin
  2. MASSEMBLY-162

In a multiproject environment, assembly takes wrong dependencies

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2-beta-2
    • Component/s: None
    • Labels:
      None

      Description

      With a projectstructure like 'Project/

      {ejb,war,ear,client}

      ' packaging the client as a fat jar-with-dependencies, it works fine using the following configuration.
      === etc/fatjar.xml ====
      <id>fat</id>
      <formats><format>jar</format></formats>
      <includeBaseDirectory>false</includeBaseDirectory>
      <fileSets><fileSet>
      <directory>target/classes</directory>
      <outputDirectory>/</outputDirectory>
      </fileSet></fileSets>
      <dependencySets>
      <dependencySet>
      <outputDirectory>/</outputDirectory>
      <unpack>true</unpack>
      <scope>runtime</scope>
      </dependencySet>
      </dependencySets>
      </assembly>
      === pom.xml ===
      <?xml version="1.0"?><project>
      <version>0.3-SNAPSHOT</version>
      <modelVersion>4.0.0</modelVersion>
      <groupId>mygroup</groupId>
      <artifactId>myapp-client</artifactId>
      <name>My Application</name>
      <dependencies>
      <!-- stripped -->
      </dependencies>
      <build>
      <plugins>
      <plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <version>2.1</version>
      <configuration>
      <descriptors><descriptor>etc/fatjar.xml</descriptor></descriptors>
      <archive>
      <manifest><mainClass>path.to.MainClass</mainClass><manifest>
      </archive>
      </configuration>
      <executions><execution>
      <phase>package</phase>
      <goals><goal>assembly</goal></goals>
      </execution></executions>
      </plugin>
      </plugins>
      </build>
      </project>

      But when I'm on the level above (packaging all) it just assembles all underlying dependencies into my clientjar, and not the dependencies of the childproject.

        Issue Links

          Activity

          Hide
          brianf@infinity.nu Brian E. Fox (imported) added a comment -

          Have you tried 2.2-SNAPSHOT? I had a similar issue with assembly:attached and it seems fixed in 2.2.

          Show
          brianf@infinity.nu Brian E. Fox (imported) added a comment - Have you tried 2.2-SNAPSHOT? I had a similar issue with assembly:attached and it seems fixed in 2.2.
          Hide
          harrol Harro Lissenberg added a comment -

          Having the same problem as the original poster I tried 2.2-SNAPSHOT but it only makes thing worse. Now creating a fat client with <unpack>true</unpack> in the assembly descriptor creates a .jar with all external dependencies unpacked in a seperate directory.
          e.g:

          myfatjar.jar
          --log4j-1.2.13
          --spring-2.0.2
          ...

          each directory then contains the unpacked jar it references to.

          Show
          harrol Harro Lissenberg added a comment - Having the same problem as the original poster I tried 2.2-SNAPSHOT but it only makes thing worse. Now creating a fat client with <unpack>true</unpack> in the assembly descriptor creates a .jar with all external dependencies unpacked in a seperate directory. e.g: myfatjar.jar --log4j-1.2.13 --spring-2.0.2 ... each directory then contains the unpacked jar it references to.
          Hide
          harrol Harro Lissenberg added a comment -

          I just noticed that the problem I have is already reported in MASSEMBLY-179

          Show
          harrol Harro Lissenberg added a comment - I just noticed that the problem I have is already reported in MASSEMBLY-179
          Hide
          richvdh Richard van der Hoff added a comment -

          Sounds like the original issue has been resolved, but replaced with MASSEMBLY-179.

          could it be marked as such?

          Show
          richvdh Richard van der Hoff added a comment - Sounds like the original issue has been resolved, but replaced with MASSEMBLY-179 . could it be marked as such?
          Hide
          lemval M. van Leeuwen added a comment -

          Since MASSEMBLY-179 now poses the problem, this one can be closed.
          I've switched to the codehaus minijar plugin, which supports ueberjars.

          Show
          lemval M. van Leeuwen added a comment - Since MASSEMBLY-179 now poses the problem, this one can be closed. I've switched to the codehaus minijar plugin, which supports ueberjars.
          Hide
          jdcasey John Casey added a comment -

          It looks like this issue has been sorted out by fixing other related issues. In 2.2-beta-1, you can eliminate the use of artifact directories using the literal: <outputFileNameMapping /> (empty element).

          In 2.2-beta-2-SNAPSHOT, I've changed it to be more like the 2.1 version, where outputFileNameMapping isn't considered when unpack == true.

          Show
          jdcasey John Casey added a comment - It looks like this issue has been sorted out by fixing other related issues. In 2.2-beta-1, you can eliminate the use of artifact directories using the literal: <outputFileNameMapping /> (empty element). In 2.2-beta-2-SNAPSHOT, I've changed it to be more like the 2.1 version, where outputFileNameMapping isn't considered when unpack == true.

            People

            • Assignee:
              jdcasey John Casey
              Reporter:
              lemval M. van Leeuwen
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development