Maven 2.x Assembly Plugin

<outputFileNameMapping> needs to report collision.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.2-beta-1
  • Fix Version/s: 2.2-beta-3
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

If <outputFileNameMapping> maps two or more artifacts into the same name, it needs to be reported as an error.

Maven currently just takes the last one without reporting anything, and as a result I didn't notice that my assembly descriptor had a problem until I debug the plugin source code.

This problem is particularly made worse by a broken jar-with-dependencies example in the documentation, which says:

  <dependencySets>
    <dependencySet>
      <outputDirectory></outputDirectory>
      <outputFileNameMapping></outputFileNameMapping>
      <unpack>true</unpack>
      <scope>runtime</scope>
    </dependencySet>
  </dependencySets>

... which maps every dependency to ""

Issue Links

Activity

Hide
Cestmír Ruzicka added a comment -

A little patch for archive duplicity.
When archiver contains artifacts file, exception is thrown

Show
Cestmír Ruzicka added a comment - A little patch for archive duplicity. When archiver contains artifacts file, exception is thrown
Hide
Cestmír Ruzicka added a comment -

Bad outputFileNameMapping is making duplicities in archive

Show
Cestmír Ruzicka added a comment - Bad outputFileNameMapping is making duplicities in archive
Hide
John Casey added a comment -

FWIW, you can now gain a little more control over this using 2.2-beta-3-SNAPSHOT latest code. The fix for MASSEMBLY-285 will also fix this, particularly if you set:

<archiverConfig>
  <duplicateBehavior>fail</duplicateBehavior>
</archiverConfig>

Admittedly, we could probably find a better way of providing a better message for specific instances where mapped artifact file names overlap, but it would be a little confusing if a mapped artifact filename overlapped with another file in the archive that wasn't the result of outputFileNameMapping logic.

Show
John Casey added a comment - FWIW, you can now gain a little more control over this using 2.2-beta-3-SNAPSHOT latest code. The fix for MASSEMBLY-285 will also fix this, particularly if you set:
<archiverConfig>
  <duplicateBehavior>fail</duplicateBehavior>
</archiverConfig>
Admittedly, we could probably find a better way of providing a better message for specific instances where mapped artifact file names overlap, but it would be a little confusing if a mapped artifact filename overlapped with another file in the archive that wasn't the result of outputFileNameMapping logic.
Hide
John Casey added a comment -

BTW, that example of the jar-with-dependencies built-in descriptor is correct; outputFileNameMapping is NOT used when unpack == true.

Show
John Casey added a comment - BTW, that example of the jar-with-dependencies built-in descriptor is correct; outputFileNameMapping is NOT used when unpack == true.

People

Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: