Maven 2.x Dependency Plugin

Unpacking artifacts should be based on type, with fallback on file-extension

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.1
  • Fix Version/s: 2.6
  • Component/s: unpack, unpack-dependencies
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

I've defined a custom lifecycle with a new packaging type "custom-ear". This type is generated by calling some external tool, which generates a (non java) ear-file. During the pre-integration-test I need to unpack it. Since dependency:unpack and dependecy:unpack-dependencies is based on the extension I'm not able to specify my own unArchiver.
Attached a patch which should fix this problem.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

Unless I misunderstand, this change would break unpacking of deps of type test-jar, bundle or any other type that effectively maps to a JAR or any other well-known file extension. So maybe either both file ext and dep type should be tried to lookup the archiver or ArtifactItem should be enriched with a new field, e.g. archiveType, that allows to explicitly denote the desired archiver type.

Show
Benjamin Bentmann added a comment - Unless I misunderstand, this change would break unpacking of deps of type test-jar , bundle or any other type that effectively maps to a JAR or any other well-known file extension. So maybe either both file ext and dep type should be tried to lookup the archiver or ArtifactItem should be enriched with a new field, e.g. archiveType , that allows to explicitly denote the desired archiver type.
Hide
Permalink
Robert Scholte added a comment -

If there's no specific UnArchiver mapping for test-jar or bundle the patch would indeed break the unpacking of those types. Introducing something like archiveType looks a bit redundant to me. The cleanest way would be to complete the components.xml with all the well-known types, the safest way would be to first check for an UnArchiver by type, next for an UnArchiver by extension.

Show
Robert Scholte added a comment - If there's no specific UnArchiver mapping for test-jar or bundle the patch would indeed break the unpacking of those types. Introducing something like archiveType looks a bit redundant to me. The cleanest way would be to complete the components.xml with all the well-known types, the safest way would be to first check for an UnArchiver by type, next for an UnArchiver by extension.
Hide
Permalink
Robert Scholte added a comment -

Fixed in r1400666

Show
Robert Scholte added a comment - Fixed in r1400666

People

  • Assignee:
    Robert Scholte
    Reporter:
    Robert Scholte
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: