Maven 2.x Shade Plugin

Shade plugin will cheerfully relocate your own classes

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0-alpha-15
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

My relocation patterns were initially too relaxed, and so they wound up relocating my own classes, rather than just the classes I depend on.

I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?)

In my case I was working on a Maven plugin; when its classes got relocated, it broke the plugin metadata... definitely not what I wanted.

Activity

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

I don't think that this is a bug. Does anyone else who watches MSHADE think that this is a bug? Absent other commentary, 'enhancement' or 'closed'.

Show
Benson Margulies added a comment - I don't think that this is a bug. Does anyone else who watches MSHADE think that this is a bug? Absent other commentary, 'enhancement' or 'closed'.
Hide
Permalink
Robert Burrell Donkin added a comment -

IMHO this isn't a bug.

Show
Robert Burrell Donkin added a comment - IMHO this isn't a bug.
Hide
Permalink
Dan Fabulich added a comment -

I filed this issue and I agree that it's an enhancement, but I don't think it should just be closed out.

Relocation patterns are very difficult to debug properly; a little more sanity checking would make Shade a lot more useable.

Show
Dan Fabulich added a comment - I filed this issue and I agree that it's an enhancement, but I don't think it should just be closed out. Relocation patterns are very difficult to debug properly; a little more sanity checking would make Shade a lot more useable.
Hide
Permalink
Robert Burrell Donkin added a comment -

IMHO debugging shade is distinct issue from verification rules for the completed build. Typically, better instrumentation with logging is a better solution to debugging problems than adding extra rules that may catch people expecting otherwise. But it's quite reasonable to want to verify that no original class has been relocated.

Been thinking that it might be useful to track the origins of resources. This would allow (for example) generation of accurate licensing information. This would also allow application of verification rules...

Show
Robert Burrell Donkin added a comment - IMHO debugging shade is distinct issue from verification rules for the completed build. Typically, better instrumentation with logging is a better solution to debugging problems than adding extra rules that may catch people expecting otherwise. But it's quite reasonable to want to verify that no original class has been relocated. Been thinking that it might be useful to track the origins of resources. This would allow (for example) generation of accurate licensing information. This would also allow application of verification rules...

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.