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
          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.
          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
          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
          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
          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
          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.

            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