works on newer versions of maven, falling back to the old way. I think we
can live with that. If anything it would be a driver for people to upgrade
;-)
On Saturday, 24 November 2012, Benson Margulies wrote:
I'm having a bit of a pause figuring out how to implement Stephen's idea.
The crux here is to tell the reactor that the official output of shade
should function in the reactor as the primary result artifact of the
current project, *without* overwriting the usual file name. Since the
jar plugin will have already attached something without a type or
classifier, another call to
org.apache.maven.project.DefaultMavenProjectHelper#attachArtifact with
null classifier and type would result in a
DuplicateArtifactAttachmentException.
I could certainly launch into an addition to the project helper API,
though I'd need some help understanding the compatibility management
of such change.
On Fri, Nov 23, 2012 at 7:22 PM, Stephen Connolly
<stephen.alan.connolly@gmail.com <javascript:;>> wrote:
--
The best argument for celibacy is that the clergy will sooner or later
become extinct.---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;><javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org<javascript:;><javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
I'm having a bit of a pause figuring out how to implement Stephen's idea.
The crux here is to tell the reactor that the official output of shade
should function in the reactor as the primary result artifact of the
current project, *without* overwriting the usual file name. Since the
jar plugin will have already attached something without a type or
classifier, another call to
org.apache.maven.project.DefaultMavenProjectHelper#attachArtifact with
null classifier and type would result in a
DuplicateArtifactAttachmentException.
I could certainly launch into an addition to the project helper API,
though I'd need some help understanding the compatibility management
of such change.
On Fri, Nov 23, 2012 at 7:22 PM, Stephen Connolly
<stephen.alan.connolly@gmail.com <javascript:;>> wrote:
And you'll recall my vote is for 3.0 (assuming the idea works and you
decide to go ahead with it, that is)
[Briefly, for anyone who is interested, the idea is to replace the artifact
attached to the reactor, rather than replace the file... Thus jar:jar's
output will be the responsibility of jar:jar and shade:shade can just
compare timestamps against its peevious output and be happy if it has a
no-op. people relying on the actual files in target having specific names
will have issues until they adapt (or switch the flag back to the pre-3.0
behaviour). People interacting with the repo will be unaffected.]
- Stephen
<javascript:;>decide to go ahead with it, that is)
[Briefly, for anyone who is interested, the idea is to replace the artifact
attached to the reactor, rather than replace the file... Thus jar:jar's
output will be the responsibility of jar:jar and shade:shade can just
compare timestamps against its peevious output and be happy if it has a
no-op. people relying on the actual files in target having specific names
will have issues until they adapt (or switch the flag back to the pre-3.0
behaviour). People interacting with the repo will be unaffected.]
- Stephen
On Friday, 23 November 2012, Benson Margulies wrote:
On Fri, Nov 23, 2012 at 4:57 PM, Jochen Wiedmann
<jochen.wiedmann@gmail.com <javascript:;> <javascript:;>> wrote:
version to be sitting in target under finalName would be broken
On Fri, Nov 23, 2012 at 10:38 PM, Benson Margulies <bimargulies@gmail.com <javascript:;> <javascript:;>>wrote:
On Fri, Nov 23, 2012 at 4:57 PM, Jochen Wiedmann
<jochen.wiedmann@gmail.com <javascript:;> <javascript:;>> wrote:
This would be an incompatible change, would it?
Yes, indeed, insofar as anyone who scripted to expect the shadedversion to be sitting in target under finalName would be broken
On Fri, Nov 23, 2012 at 10:38 PM, Benson Margulies <
I want to take up a suggestion of Stephen Connolly and fix the
interactions between shade and jar by changing the default file name
of 'replacing' shaded jars. I'd like incremental jar-ing to work by
default, so I want to change the default behavior. 2.1 or 3.0?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;><javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
interactions between shade and jar by changing the default file name
of 'replacing' shaded jars. I'd like incremental jar-ing to work by
default, so I want to change the default behavior. 2.1 or 3.0?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;><javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
--
The best argument for celibacy is that the clergy will sooner or later
become extinct.
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;><javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org<javascript:;><javascript:;>
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
