Maven 2.x Assembly Plugin

In a multiproject environment, assembly takes wrong dependencies

Details

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

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
Brian Fox 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
Brian Fox 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
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
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
Harro Lissenberg added a comment -

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

Show
Harro Lissenberg added a comment - I just noticed that the problem I have is already reported in MASSEMBLY-179
Hide
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
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
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
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
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
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

Vote (1)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: