I like this.
On Fri, Jun 29, 2012 at 9:48 AM, Stephen Connolly
wrote:
> 3) add a shade:clean goal which removes the jar and let people bind
> that to prepare-package
>
> On 29 June 2012 14:28, Benson Margulies wrote:
>> OK, now I understand this.
>>
>> The jar plugin will optimize out writing a
3) add a shade:clean goal which removes the jar and let people bind
that to prepare-package
On 29 June 2012 14:28, Benson Margulies wrote:
> OK, now I understand this.
>
> The jar plugin will optimize out writing a jar in some cases.
>
> This is never a good idea is shade has produced the jar. Bu
OK, now I understand this.
The jar plugin will optimize out writing a jar in some cases.
This is never a good idea is shade has produced the jar. But the jar
plugin has no way, I can see, to notice this. So the jar plugin leaves
the shaded jar and then shade explodes.
I can see two possible appr
Cancel this thought. The jar plugin purports to run first.
On Fri, Jun 29, 2012 at 9:12 AM, Benson Margulies wrote:
> https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result
> from a Pretty Dumb Thing. I suspect that the problem is that the jar
> plugin has ended up in the packaging
https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result
from a Pretty Dumb Thing. I suspect that the problem is that the jar
plugin has ended up in the packaging phase AFTER the shade plugin, due
to the way that plugin management and plugin elements merge.
Does this make any sense to
