Maven 2.x Shade Plugin

Running shade twice without clean leads to warnings and errors

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.7.1
  • Fix Version/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    3

Description

Frequently, when I run a build without 'clean', I get a torrent of unwanted 'duplicate symbol' errors from shade. More recently, when I did the same for a build that includes some shading that combines files from META-INF, this turned into a fatal error.

I've managed to produce a repro with maven 3.0.4. Just run 'mvn install' twice in a row to reproduce this. The impression it gives is that, somehow, the shaded jar from the previous build is used as the input, instead of a new jar built from scratch this time around.

  1. XML File
    epom.xml
    29/Jun/12 7:59 AM
    65 kB
    Benson Margulies
  2. Text File
    shade.boom.log
    29/Jun/12 7:55 AM
    1.16 MB
    Benson Margulies
  3. File
    shade-error.tgz
    29/Jun/12 8:09 AM
    2 kB
    Benson Margulies

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benson Margulies added a comment -

Here is -X of a failure on a project of mine. I'm so-far failing to make it fail on a small example.

Show
Benson Margulies added a comment - Here is -X of a failure on a project of mine. I'm so-far failing to make it fail on a small example.
Hide
Permalink
Benson Margulies added a comment -

Here is the effective pom.

Show
Benson Margulies added a comment - Here is the effective pom.
Hide
Permalink
Benson Margulies added a comment -

Here is a failing test case!

Show
Benson Margulies added a comment - Here is a failing test case!
Hide
Permalink
Benson Margulies added a comment -

Adding <forceCreation>true</forceCreation> to the maven-jar-plugin works around this.

Show
Benson Margulies added a comment - Adding <forceCreation>true</forceCreation> to the maven-jar-plugin works around this.
Hide
Permalink
Benson Margulies added a comment -

Here's an idea to fix this:

3) add a shade:clean goal which removes the jar and let people bind
that to prepare-package

Show
Benson Margulies added a comment - Here's an idea to fix this: 3) add a shade:clean goal which removes the jar and let people bind that to prepare-package
Hide
Permalink
Stephen Buergler added a comment -

How about adding a file that marks it as a shaded jar?

Show
Stephen Buergler added a comment - How about adding a file that marks it as a shaded jar?
Hide
Permalink
Benson Margulies added a comment -

A real fix to this is a big job. To comprehensively fix this, you'd need:

  1. shade to keep the pre-shaded jar around under some name
  2. shade to detect when there's a good reason to rebuild the pre-shaded jar, including changes to dependencies.

Without all this, changing the config of the jar plugin is the best thing.

Show
Benson Margulies added a comment - A real fix to this is a big job. To comprehensively fix this, you'd need: shade to keep the pre-shaded jar around under some name shade to detect when there's a good reason to rebuild the pre-shaded jar, including changes to dependencies. Without all this, changing the config of the jar plugin is the best thing.

People

  • Assignee:
    Unassigned
    Reporter:
    Benson Margulies
Vote (2)
Watch (4)

Dates

  • Created:
    Updated: