Maven 2.x Ear Plugin

skinnyWars and SNAPSHOT unique dependencies

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.7
  • Fix Version/s: 2.8.1
  • Labels:
    None
  • Environment:
    All
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

When trying to create skinnyWars, any SNAPSHOTS dependencies are not extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. The AbstractFileNameMapping class uses the baseVersion to generate the filename which doesn't take into account timestamp dependencies, therefore the plugin is unable to delete any dependency in the libDir folder. Using the Artifact.version property will produce the correct filename for deletion.

The really only affects DEV-produced artifacts where EARs are built for deployment and testing. Additionally, bloated EARs can affect repository managers where excessive disk space may not be available.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Paul Vonnahme added a comment -

I'm also seeing this issue.

I'll also point out that if the person who built the war was using <outputFileNameMapping> feature of the war plugin, the ear plugin may not match any of the file names. Maybe you will need to have a <skinnyWarOutputFileNameMapping> option? Or would it be possible to pull the mapping from the war's pom.xml? In any case, I see that as a smaller issue than the SNAPSHOT dependencies. Ideally for now this patch could be applied, and support for <outputFileNameMapping> could be deferred if it's more of a major undertaking.

In any case, the <skinnyWars> option is a great feature to have and I'm excited to see it mature.

Show
Paul Vonnahme added a comment - I'm also seeing this issue. I'll also point out that if the person who built the war was using <outputFileNameMapping> feature of the war plugin, the ear plugin may not match any of the file names. Maybe you will need to have a <skinnyWarOutputFileNameMapping> option? Or would it be possible to pull the mapping from the war's pom.xml? In any case, I see that as a smaller issue than the SNAPSHOT dependencies. Ideally for now this patch could be applied, and support for <outputFileNameMapping> could be deferred if it's more of a major undertaking. In any case, the <skinnyWars> option is a great feature to have and I'm excited to see it mature.
Hide
Permalink
Geert Schuring added a comment - - edited

I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch?

Some detail about our situation: Because some jar is present twice in the ear file (once in ear file, and once in embedded war file), Weld throws an exception because it finds 2 candidates for 1 injection point and our ears cannot be deployed on our application server (Glassfish 3).

Show
Geert Schuring added a comment - - edited I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch? Some detail about our situation: Because some jar is present twice in the ear file (once in ear file, and once in embedded war file), Weld throws an exception because it finds 2 candidates for 1 injection point and our ears cannot be deployed on our application server (Glassfish 3).

People

  • Assignee:
    Unassigned
    Reporter:
    Seth Rife
Vote (7)
Watch (5)

Dates

  • Created:
    Updated: