You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2012/11/25 16:55:58 UTC
Shade and it's many options for controlling output
Shade has a collection of related parameters for controlling where the
results end up. To me, they feel like a collection of individual items
that are fairly confusing to the reader of the documentation.
Since I'm planning to bump the major version and change the behavior,
I'd like to consider rationalizing all of them.
It seems to me that there are, in fact, three modes of operation:
1) replace the primary artifact of the project.
2) attach an artifact with the user's choice of artifactId and classifier.
3) just drop a file someplace.
In modes (1) and (2), it's also reasonable for the user to control the
filename in the output directory, since every other plugin seems to
allow that.
So, what do people think of the following:
Four parameters:
<attach>true/false</attach>
<attachArtifact>
<artifactId/>
<classifier/>
</attachArtifact>
<outputDirectory/>
<finalName/>
This puts all the information about the attached result in one place.
Shade is the only plugin I know that allows you to attach with your
choice of artifactId.
To replace the primary artifact, the user would write:
<artifactId>${project.artifactId}</artifactId>
<classifier/>
The defaults would be:
<attach>true</attach>
<attachArtifactId>
<artifactId>${project.artifactId}</artifactId>
<classifier>shaded</classifier>
</attachArtifactId>
<outputDirectory>${project.buildDirectory}</outputDirectory>
<finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Benson Margulies <bi...@gmail.com>.
More thought leads me toward additional simplification.
I don't see why individual plugins need individual settings of
outputDirectory. If the output is going into the reactor, I think it
should be, by convention, in the project output directory, period.
This is related to Anders' hatred of finalName. Let's start with his
policy, that anyone who so badly wants to mess with naming is welcome
to run antrun.
This would give us, perhaps:
<outputFile/> -- if set, no attachment, and it determines the complete
pathname of the result.
<attach/> -- just like assembly and others, if true, attach. if false,
don't, and default the value of outputFile.
<classifier/> -- only read if attach=true, changes classifier from 'shaded'.
<replacePrimaryArtifact/> -- if true, replaces the primary artifact (boolean)
Eliminating outputDirectory, shadedArtifactId,
This appeals to me because I prefer to make the 'replacement' behavior
very explicit.
On the other hand, it seems as if 'sources' are underspecified. It
would seem to be relevant to have a param to control the classifier of
the created sources jar, since calling it just 'sources' as a
classifier when not replacing the primary artifact doesn't make sense.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Stephen Connolly <st...@gmail.com>.
I've had a look at the code. Kill it!
On 25 November 2012 20:22, Benson Margulies <bi...@gmail.com> wrote:
> Given that all it turns out to *do* is to construct finalName, I am
> perfectly willing to kill it. If bentmann decides to relax his vow of
> never talking to us, I'm happy to hear what he says.
>
>
> On Sun, Nov 25, 2012 at 2:58 PM, Stephen Connolly
> <st...@gmail.com> wrote:
> > No. Not expected to remember... But sometimes one does... especially
> > bentmann in my experience ;-)
> >
> > On Sunday, 25 November 2012, Anders Hammar wrote:
> >
> >> Just a check, is one supposed to remember why one did something 4.5
> years
> >> ago? I can hardly remember what I did last week....
> >>
> >> I'm currently searching JIRA to see if I can find a ticket that would
> match
> >> Benjamin's fix.
> >>
> >> /Anders
> >>
> >>
> >> On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >> > So it is not to create the shaded artifact at a different coordinate
> >> > without requiring the creation of an additional module?
> >> >
> >> > I agree it seems a tad insane, but if we could get bentmann to chime
> in
> >> as
> >> > to what it is actually supposed to do, then I think we can make a
> correct
> >> > decision...
> >> >
> >> > Of course the code may not work... Which is a different issue...
> >> >
> >> > But having to create a module with a Pom that has to be kept in sync
> just
> >> > to put the shaded artifact with dependency reduced Pom at a different
> >> > coordinate... Does seem wasteful... Otoh how is the reactor to know
> the
> >> > artifact will magically appear and hence produce the correct build
> >> plan...
> >> >
> >> > So I have nearly convinced myself that it is insane... But let's ask!
> >> >
> >> > On Sunday, 25 November 2012, Benson Margulies wrote:
> >> >
> >> > > I am fairly depressed here, and I agree with Anders.
> >> > >
> >> > > The shadedArtifactId was added in svn rev 640405 by bbentman.
> >> > >
> >> > > The log for that change consists of:
> >> > >
> >> > >
> >> ------------------------------------------------------------------------
> >> > > r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) |
> 1
> >> > line
> >> > >
> >> > > o Added svn:eol-style=native
> >> > >
> >> ------------------------------------------------------------------------
> >> > >
> >> > > That really does not shed any light. Further, the name is completely
> >> > > misleading. it does not, in fact, change how the attach happens, it
> is
> >> > > just a baroque means of specifying the final name in pieces. So I
> >> > > modify my proposal to consist of:
> >> > >
> >> > > attach
> >> > >
> >> > > attachClassifier
> >> > >
> >> > > outputDirectory
> >> > >
> >> > > finalName
> >> > >
> >> > > no sub-objects.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <
> >> bimargulies@gmail.com
> >> > >
> >> > > wrote:
> >> > > > Anders,
> >> > > >
> >> > > > I'm willing to go on a history expedition to see who added the
> >> > > > feature. The MavenProjectHelper API suports this feature, let
> alone
> >> > > > the naked MavenProject API.
> >> > > >
> >> > > >
> >> > > > On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <anders@hammar.net
> >
> >> > > wrote:
> >> > > >>> > How would you attach an artifact with a DIFFERENT artifactId
> than
> >> > the
> >> > > >>> > project? It doesn't make sense.
> >> > > >>>
> >> > > >>> This is *already* a feature of the plugin. I didn't invent it,
> I'm
> >> > > >>> just trying to clean up how your configure it.
> >> > > >>>
> >> > > >>
> >> > > >> Why would you try to clean up how to configure something that
> >> doesn't
> >> > > make
> >> > > >> sense and is plain wrong? Maven is about best-practices and we
> >> should
> >> > > help
> >> > > >> people do the right thing.
> >> > > >>
> >> > > >> And btw, finalName should be nuked out of the Maven world. :-)
> >> > > >>
> >> > > >> /Anders
> >> > > >>
> >> > > >>
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>> >
> >> > > >>> > I would vote for doing changes that make it impossible to use
> the
> >> > > plugin
> >> > > >>> as
> >> > > >>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant
> >> > solution.
> >> > > I
> >> > > >>> > think that the possibilities to alter the final name of the
> built
> >> > > >>> artifact
> >> > > >>> > fools people into thinking that you can specify the name of
> the
> >> > > artifact.
> >> > > >>> > You migth be able to specify the name of the build file in the
> >> > build
> >> > > >>> > folder, but that's not something you should create a build
> >> solution
> >> > > >>> around.
> >> > > >>>
> >> > > >>> Well, finalName in the pom it
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Shade and it's many options for controlling output
Posted by Benson Margulies <bi...@gmail.com>.
Given that all it turns out to *do* is to construct finalName, I am
perfectly willing to kill it. If bentmann decides to relax his vow of
never talking to us, I'm happy to hear what he says.
On Sun, Nov 25, 2012 at 2:58 PM, Stephen Connolly
<st...@gmail.com> wrote:
> No. Not expected to remember... But sometimes one does... especially
> bentmann in my experience ;-)
>
> On Sunday, 25 November 2012, Anders Hammar wrote:
>
>> Just a check, is one supposed to remember why one did something 4.5 years
>> ago? I can hardly remember what I did last week....
>>
>> I'm currently searching JIRA to see if I can find a ticket that would match
>> Benjamin's fix.
>>
>> /Anders
>>
>>
>> On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> > So it is not to create the shaded artifact at a different coordinate
>> > without requiring the creation of an additional module?
>> >
>> > I agree it seems a tad insane, but if we could get bentmann to chime in
>> as
>> > to what it is actually supposed to do, then I think we can make a correct
>> > decision...
>> >
>> > Of course the code may not work... Which is a different issue...
>> >
>> > But having to create a module with a Pom that has to be kept in sync just
>> > to put the shaded artifact with dependency reduced Pom at a different
>> > coordinate... Does seem wasteful... Otoh how is the reactor to know the
>> > artifact will magically appear and hence produce the correct build
>> plan...
>> >
>> > So I have nearly convinced myself that it is insane... But let's ask!
>> >
>> > On Sunday, 25 November 2012, Benson Margulies wrote:
>> >
>> > > I am fairly depressed here, and I agree with Anders.
>> > >
>> > > The shadedArtifactId was added in svn rev 640405 by bbentman.
>> > >
>> > > The log for that change consists of:
>> > >
>> > >
>> ------------------------------------------------------------------------
>> > > r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1
>> > line
>> > >
>> > > o Added svn:eol-style=native
>> > >
>> ------------------------------------------------------------------------
>> > >
>> > > That really does not shed any light. Further, the name is completely
>> > > misleading. it does not, in fact, change how the attach happens, it is
>> > > just a baroque means of specifying the final name in pieces. So I
>> > > modify my proposal to consist of:
>> > >
>> > > attach
>> > >
>> > > attachClassifier
>> > >
>> > > outputDirectory
>> > >
>> > > finalName
>> > >
>> > > no sub-objects.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <
>> bimargulies@gmail.com
>> > >
>> > > wrote:
>> > > > Anders,
>> > > >
>> > > > I'm willing to go on a history expedition to see who added the
>> > > > feature. The MavenProjectHelper API suports this feature, let alone
>> > > > the naked MavenProject API.
>> > > >
>> > > >
>> > > > On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net>
>> > > wrote:
>> > > >>> > How would you attach an artifact with a DIFFERENT artifactId than
>> > the
>> > > >>> > project? It doesn't make sense.
>> > > >>>
>> > > >>> This is *already* a feature of the plugin. I didn't invent it, I'm
>> > > >>> just trying to clean up how your configure it.
>> > > >>>
>> > > >>
>> > > >> Why would you try to clean up how to configure something that
>> doesn't
>> > > make
>> > > >> sense and is plain wrong? Maven is about best-practices and we
>> should
>> > > help
>> > > >> people do the right thing.
>> > > >>
>> > > >> And btw, finalName should be nuked out of the Maven world. :-)
>> > > >>
>> > > >> /Anders
>> > > >>
>> > > >>
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> >
>> > > >>> > I would vote for doing changes that make it impossible to use the
>> > > plugin
>> > > >>> as
>> > > >>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant
>> > solution.
>> > > I
>> > > >>> > think that the possibilities to alter the final name of the built
>> > > >>> artifact
>> > > >>> > fools people into thinking that you can specify the name of the
>> > > artifact.
>> > > >>> > You migth be able to specify the name of the build file in the
>> > build
>> > > >>> > folder, but that's not something you should create a build
>> solution
>> > > >>> around.
>> > > >>>
>> > > >>> Well, finalName in the pom it
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Stephen Connolly <st...@gmail.com>.
No. Not expected to remember... But sometimes one does... especially
bentmann in my experience ;-)
On Sunday, 25 November 2012, Anders Hammar wrote:
> Just a check, is one supposed to remember why one did something 4.5 years
> ago? I can hardly remember what I did last week....
>
> I'm currently searching JIRA to see if I can find a ticket that would match
> Benjamin's fix.
>
> /Anders
>
>
> On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > So it is not to create the shaded artifact at a different coordinate
> > without requiring the creation of an additional module?
> >
> > I agree it seems a tad insane, but if we could get bentmann to chime in
> as
> > to what it is actually supposed to do, then I think we can make a correct
> > decision...
> >
> > Of course the code may not work... Which is a different issue...
> >
> > But having to create a module with a Pom that has to be kept in sync just
> > to put the shaded artifact with dependency reduced Pom at a different
> > coordinate... Does seem wasteful... Otoh how is the reactor to know the
> > artifact will magically appear and hence produce the correct build
> plan...
> >
> > So I have nearly convinced myself that it is insane... But let's ask!
> >
> > On Sunday, 25 November 2012, Benson Margulies wrote:
> >
> > > I am fairly depressed here, and I agree with Anders.
> > >
> > > The shadedArtifactId was added in svn rev 640405 by bbentman.
> > >
> > > The log for that change consists of:
> > >
> > >
> ------------------------------------------------------------------------
> > > r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1
> > line
> > >
> > > o Added svn:eol-style=native
> > >
> ------------------------------------------------------------------------
> > >
> > > That really does not shed any light. Further, the name is completely
> > > misleading. it does not, in fact, change how the attach happens, it is
> > > just a baroque means of specifying the final name in pieces. So I
> > > modify my proposal to consist of:
> > >
> > > attach
> > >
> > > attachClassifier
> > >
> > > outputDirectory
> > >
> > > finalName
> > >
> > > no sub-objects.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <
> bimargulies@gmail.com
> > >
> > > wrote:
> > > > Anders,
> > > >
> > > > I'm willing to go on a history expedition to see who added the
> > > > feature. The MavenProjectHelper API suports this feature, let alone
> > > > the naked MavenProject API.
> > > >
> > > >
> > > > On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net>
> > > wrote:
> > > >>> > How would you attach an artifact with a DIFFERENT artifactId than
> > the
> > > >>> > project? It doesn't make sense.
> > > >>>
> > > >>> This is *already* a feature of the plugin. I didn't invent it, I'm
> > > >>> just trying to clean up how your configure it.
> > > >>>
> > > >>
> > > >> Why would you try to clean up how to configure something that
> doesn't
> > > make
> > > >> sense and is plain wrong? Maven is about best-practices and we
> should
> > > help
> > > >> people do the right thing.
> > > >>
> > > >> And btw, finalName should be nuked out of the Maven world. :-)
> > > >>
> > > >> /Anders
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>> >
> > > >>> > I would vote for doing changes that make it impossible to use the
> > > plugin
> > > >>> as
> > > >>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant
> > solution.
> > > I
> > > >>> > think that the possibilities to alter the final name of the built
> > > >>> artifact
> > > >>> > fools people into thinking that you can specify the name of the
> > > artifact.
> > > >>> > You migth be able to specify the name of the build file in the
> > build
> > > >>> > folder, but that's not something you should create a build
> solution
> > > >>> around.
> > > >>>
> > > >>> Well, finalName in the pom it
Re: Shade and it's many options for controlling output
Posted by Anders Hammar <an...@hammar.net>.
Just a check, is one supposed to remember why one did something 4.5 years
ago? I can hardly remember what I did last week....
I'm currently searching JIRA to see if I can find a ticket that would match
Benjamin's fix.
/Anders
On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> So it is not to create the shaded artifact at a different coordinate
> without requiring the creation of an additional module?
>
> I agree it seems a tad insane, but if we could get bentmann to chime in as
> to what it is actually supposed to do, then I think we can make a correct
> decision...
>
> Of course the code may not work... Which is a different issue...
>
> But having to create a module with a Pom that has to be kept in sync just
> to put the shaded artifact with dependency reduced Pom at a different
> coordinate... Does seem wasteful... Otoh how is the reactor to know the
> artifact will magically appear and hence produce the correct build plan...
>
> So I have nearly convinced myself that it is insane... But let's ask!
>
> On Sunday, 25 November 2012, Benson Margulies wrote:
>
> > I am fairly depressed here, and I agree with Anders.
> >
> > The shadedArtifactId was added in svn rev 640405 by bbentman.
> >
> > The log for that change consists of:
> >
> > ------------------------------------------------------------------------
> > r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1
> line
> >
> > o Added svn:eol-style=native
> > ------------------------------------------------------------------------
> >
> > That really does not shed any light. Further, the name is completely
> > misleading. it does not, in fact, change how the attach happens, it is
> > just a baroque means of specifying the final name in pieces. So I
> > modify my proposal to consist of:
> >
> > attach
> >
> > attachClassifier
> >
> > outputDirectory
> >
> > finalName
> >
> > no sub-objects.
> >
> >
> >
> >
> >
> >
> > On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> > > Anders,
> > >
> > > I'm willing to go on a history expedition to see who added the
> > > feature. The MavenProjectHelper API suports this feature, let alone
> > > the naked MavenProject API.
> > >
> > >
> > > On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net>
> > wrote:
> > >>> > How would you attach an artifact with a DIFFERENT artifactId than
> the
> > >>> > project? It doesn't make sense.
> > >>>
> > >>> This is *already* a feature of the plugin. I didn't invent it, I'm
> > >>> just trying to clean up how your configure it.
> > >>>
> > >>
> > >> Why would you try to clean up how to configure something that doesn't
> > make
> > >> sense and is plain wrong? Maven is about best-practices and we should
> > help
> > >> people do the right thing.
> > >>
> > >> And btw, finalName should be nuked out of the Maven world. :-)
> > >>
> > >> /Anders
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>> >
> > >>> > I would vote for doing changes that make it impossible to use the
> > plugin
> > >>> as
> > >>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant
> solution.
> > I
> > >>> > think that the possibilities to alter the final name of the built
> > >>> artifact
> > >>> > fools people into thinking that you can specify the name of the
> > artifact.
> > >>> > You migth be able to specify the name of the build file in the
> build
> > >>> > folder, but that's not something you should create a build solution
> > >>> around.
> > >>>
> > >>> Well, finalName in the pom itself has this effect on the main
> > >>> artifact, so, for better or worse, people build things that depend on
> > >>> it all the time. *I* build things that depend on the use of the pom
> > >>> element to flush version numbers from war files.
> > >>>
> > >>> So I, personally, am not comfortable with flushing finalName from the
> > >>> picture.
> > >>>
> > >>>
> > >>> >
> > >>> > /Anders
> > >>> >
> > >>> >
> > >>> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <
> > bimargulies@gmail.com
> > >>> >wrote:
> > >>> >
> > >>> >> Shade has a collection of related parameters for controlling where
> > the
> > >>> >> results end up. To me, they feel like a collection of individual
> > items
> > >>> >> that are fairly confusing to the reader of the documentation.
> > >>> >>
> > >>> >> Since I'm planning to bump the major version and change the
> > behavior,
> > >>> >> I'd like to consider rationalizing all of them.
> > >>> >>
> > >>> >> It seems to me that there are, in fact, three modes of operation:
> > >>> >>
> > >>> >> 1) replace the primary artifact of the project.
> > >>> >> 2) attach an artifact with the user's choice of artifactId and
> > >>> classifier.
> > >>> >> 3) just drop a file someplace.
> > >>> >>
> > >>> >> In modes (1) and (2), it's also reasonable for the user to control
> > the
> > >>> >> filename in the output directory, since every other plugin seems
> to
> > >>> >> allow that.
> > >>> >>
> > >>> >> So, what do people think of the following:
> > >>> >>
> > >>> >> Four parameters:
> > >>> >>
> > >>> >> <attach>true/false</attach>
> > >>> >>
> > >>> >> <attachArtifact>
> > >>> >> <artifactId/>
> > >>> >> <classifier/>
> > >>> >> </attachArtifact>
> > >>> >>
> > >>> >> <outputDirectory/>
> > >>> >> <finalName/>
> > >>> >>
> > >>> >> This puts all the information about the attached result in one
> > place.
> > >>> >> Shade is the only plugin I know that allows you to attach with
> your
> > >>> >> choice of artifactId.
> > >>> >>
> > >>> >> To replace the primary artifact,
>
Re: Shade and it's many options for controlling output
Posted by Stephen Connolly <st...@gmail.com>.
So it is not to create the shaded artifact at a different coordinate
without requiring the creation of an additional module?
I agree it seems a tad insane, but if we could get bentmann to chime in as
to what it is actually supposed to do, then I think we can make a correct
decision...
Of course the code may not work... Which is a different issue...
But having to create a module with a Pom that has to be kept in sync just
to put the shaded artifact with dependency reduced Pom at a different
coordinate... Does seem wasteful... Otoh how is the reactor to know the
artifact will magically appear and hence produce the correct build plan...
So I have nearly convinced myself that it is insane... But let's ask!
On Sunday, 25 November 2012, Benson Margulies wrote:
> I am fairly depressed here, and I agree with Anders.
>
> The shadedArtifactId was added in svn rev 640405 by bbentman.
>
> The log for that change consists of:
>
> ------------------------------------------------------------------------
> r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1 line
>
> o Added svn:eol-style=native
> ------------------------------------------------------------------------
>
> That really does not shed any light. Further, the name is completely
> misleading. it does not, in fact, change how the attach happens, it is
> just a baroque means of specifying the final name in pieces. So I
> modify my proposal to consist of:
>
> attach
>
> attachClassifier
>
> outputDirectory
>
> finalName
>
> no sub-objects.
>
>
>
>
>
>
> On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> > Anders,
> >
> > I'm willing to go on a history expedition to see who added the
> > feature. The MavenProjectHelper API suports this feature, let alone
> > the naked MavenProject API.
> >
> >
> > On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net>
> wrote:
> >>> > How would you attach an artifact with a DIFFERENT artifactId than the
> >>> > project? It doesn't make sense.
> >>>
> >>> This is *already* a feature of the plugin. I didn't invent it, I'm
> >>> just trying to clean up how your configure it.
> >>>
> >>
> >> Why would you try to clean up how to configure something that doesn't
> make
> >> sense and is plain wrong? Maven is about best-practices and we should
> help
> >> people do the right thing.
> >>
> >> And btw, finalName should be nuked out of the Maven world. :-)
> >>
> >> /Anders
> >>
> >>
> >>>
> >>>
> >>>
> >>> >
> >>> > I would vote for doing changes that make it impossible to use the
> plugin
> >>> as
> >>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution.
> I
> >>> > think that the possibilities to alter the final name of the built
> >>> artifact
> >>> > fools people into thinking that you can specify the name of the
> artifact.
> >>> > You migth be able to specify the name of the build file in the build
> >>> > folder, but that's not something you should create a build solution
> >>> around.
> >>>
> >>> Well, finalName in the pom itself has this effect on the main
> >>> artifact, so, for better or worse, people build things that depend on
> >>> it all the time. *I* build things that depend on the use of the pom
> >>> element to flush version numbers from war files.
> >>>
> >>> So I, personally, am not comfortable with flushing finalName from the
> >>> picture.
> >>>
> >>>
> >>> >
> >>> > /Anders
> >>> >
> >>> >
> >>> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <
> bimargulies@gmail.com
> >>> >wrote:
> >>> >
> >>> >> Shade has a collection of related parameters for controlling where
> the
> >>> >> results end up. To me, they feel like a collection of individual
> items
> >>> >> that are fairly confusing to the reader of the documentation.
> >>> >>
> >>> >> Since I'm planning to bump the major version and change the
> behavior,
> >>> >> I'd like to consider rationalizing all of them.
> >>> >>
> >>> >> It seems to me that there are, in fact, three modes of operation:
> >>> >>
> >>> >> 1) replace the primary artifact of the project.
> >>> >> 2) attach an artifact with the user's choice of artifactId and
> >>> classifier.
> >>> >> 3) just drop a file someplace.
> >>> >>
> >>> >> In modes (1) and (2), it's also reasonable for the user to control
> the
> >>> >> filename in the output directory, since every other plugin seems to
> >>> >> allow that.
> >>> >>
> >>> >> So, what do people think of the following:
> >>> >>
> >>> >> Four parameters:
> >>> >>
> >>> >> <attach>true/false</attach>
> >>> >>
> >>> >> <attachArtifact>
> >>> >> <artifactId/>
> >>> >> <classifier/>
> >>> >> </attachArtifact>
> >>> >>
> >>> >> <outputDirectory/>
> >>> >> <finalName/>
> >>> >>
> >>> >> This puts all the information about the attached result in one
> place.
> >>> >> Shade is the only plugin I know that allows you to attach with your
> >>> >> choice of artifactId.
> >>> >>
> >>> >> To replace the primary artifact,
Re: Shade and it's many options for controlling output
Posted by Benson Margulies <bi...@gmail.com>.
I am fairly depressed here, and I agree with Anders.
The shadedArtifactId was added in svn rev 640405 by bbentman.
The log for that change consists of:
------------------------------------------------------------------------
r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1 line
o Added svn:eol-style=native
------------------------------------------------------------------------
That really does not shed any light. Further, the name is completely
misleading. it does not, in fact, change how the attach happens, it is
just a baroque means of specifying the final name in pieces. So I
modify my proposal to consist of:
attach
attachClassifier
outputDirectory
finalName
no sub-objects.
On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <bi...@gmail.com> wrote:
> Anders,
>
> I'm willing to go on a history expedition to see who added the
> feature. The MavenProjectHelper API suports this feature, let alone
> the naked MavenProject API.
>
>
> On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net> wrote:
>>> > How would you attach an artifact with a DIFFERENT artifactId than the
>>> > project? It doesn't make sense.
>>>
>>> This is *already* a feature of the plugin. I didn't invent it, I'm
>>> just trying to clean up how your configure it.
>>>
>>
>> Why would you try to clean up how to configure something that doesn't make
>> sense and is plain wrong? Maven is about best-practices and we should help
>> people do the right thing.
>>
>> And btw, finalName should be nuked out of the Maven world. :-)
>>
>> /Anders
>>
>>
>>>
>>>
>>>
>>> >
>>> > I would vote for doing changes that make it impossible to use the plugin
>>> as
>>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
>>> > think that the possibilities to alter the final name of the built
>>> artifact
>>> > fools people into thinking that you can specify the name of the artifact.
>>> > You migth be able to specify the name of the build file in the build
>>> > folder, but that's not something you should create a build solution
>>> around.
>>>
>>> Well, finalName in the pom itself has this effect on the main
>>> artifact, so, for better or worse, people build things that depend on
>>> it all the time. *I* build things that depend on the use of the pom
>>> element to flush version numbers from war files.
>>>
>>> So I, personally, am not comfortable with flushing finalName from the
>>> picture.
>>>
>>>
>>> >
>>> > /Anders
>>> >
>>> >
>>> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <bimargulies@gmail.com
>>> >wrote:
>>> >
>>> >> Shade has a collection of related parameters for controlling where the
>>> >> results end up. To me, they feel like a collection of individual items
>>> >> that are fairly confusing to the reader of the documentation.
>>> >>
>>> >> Since I'm planning to bump the major version and change the behavior,
>>> >> I'd like to consider rationalizing all of them.
>>> >>
>>> >> It seems to me that there are, in fact, three modes of operation:
>>> >>
>>> >> 1) replace the primary artifact of the project.
>>> >> 2) attach an artifact with the user's choice of artifactId and
>>> classifier.
>>> >> 3) just drop a file someplace.
>>> >>
>>> >> In modes (1) and (2), it's also reasonable for the user to control the
>>> >> filename in the output directory, since every other plugin seems to
>>> >> allow that.
>>> >>
>>> >> So, what do people think of the following:
>>> >>
>>> >> Four parameters:
>>> >>
>>> >> <attach>true/false</attach>
>>> >>
>>> >> <attachArtifact>
>>> >> <artifactId/>
>>> >> <classifier/>
>>> >> </attachArtifact>
>>> >>
>>> >> <outputDirectory/>
>>> >> <finalName/>
>>> >>
>>> >> This puts all the information about the attached result in one place.
>>> >> Shade is the only plugin I know that allows you to attach with your
>>> >> choice of artifactId.
>>> >>
>>> >> To replace the primary artifact, the user would write:
>>> >>
>>> >> <artifactId>${project.artifactId}</artifactId>
>>> >> <classifier/>
>>> >>
>>> >> The defaults would be:
>>> >>
>>> >> <attach>true</attach>
>>> >>
>>> >> <attachArtifactId>
>>> >> <artifactId>${project.artifactId}</artifactId>
>>> >> <classifier>shaded</classifier>
>>> >> </attachArtifactId>
>>> >>
>>> >> <outputDirectory>${project.buildDirectory}</outputDirectory>
>>> >>
>>> >>
>>> >>
>>> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Anders Hammar <an...@hammar.net>.
> I'm willing to go on a history expedition to see who added the
> feature. The MavenProjectHelper API suports this feature, let alone
> the naked MavenProject API.
>
I don't care who initially added this, just saying that if we're to do any
changes here it should be to fix errors not to refine them. I simply can't
see how you could attach an artifact with a different artifactId. Does it
even work? It will be without a pom then, or what?
Looking at the MavenProject API I only see:
public void addAttachedArtifact( Artifact artifact )
I don't take it that the idea is to add an artifact with a different
artifactId, but rather that we're using the model object (Artifact). I
would hope that it will throw an exception if the artifactId isn't the same
as the project's.
/Anders
>
>
> On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net> wrote:
> >> > How would you attach an artifact with a DIFFERENT artifactId than the
> >> > project? It doesn't make sense.
> >>
> >> This is *already* a feature of the plugin. I didn't invent it, I'm
> >> just trying to clean up how your configure it.
> >>
> >
> > Why would you try to clean up how to configure something that doesn't
> make
> > sense and is plain wrong? Maven is about best-practices and we should
> help
> > people do the right thing.
> >
> > And btw, finalName should be nuked out of the Maven world. :-)
> >
> > /Anders
> >
> >
> >>
> >>
> >>
> >> >
> >> > I would vote for doing changes that make it impossible to use the
> plugin
> >> as
> >> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
> >> > think that the possibilities to alter the final name of the built
> >> artifact
> >> > fools people into thinking that you can specify the name of the
> artifact.
> >> > You migth be able to specify the name of the build file in the build
> >> > folder, but that's not something you should create a build solution
> >> around.
> >>
> >> Well, finalName in the pom itself has this effect on the main
> >> artifact, so, for better or worse, people build things that depend on
> >> it all the time. *I* build things that depend on the use of the pom
> >> element to flush version numbers from war files.
> >>
> >> So I, personally, am not comfortable with flushing finalName from the
> >> picture.
> >>
> >>
> >> >
> >> > /Anders
> >> >
> >> >
> >> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <
> bimargulies@gmail.com
> >> >wrote:
> >> >
> >> >> Shade has a collection of related parameters for controlling where
> the
> >> >> results end up. To me, they feel like a collection of individual
> items
> >> >> that are fairly confusing to the reader of the documentation.
> >> >>
> >> >> Since I'm planning to bump the major version and change the behavior,
> >> >> I'd like to consider rationalizing all of them.
> >> >>
> >> >> It seems to me that there are, in fact, three modes of operation:
> >> >>
> >> >> 1) replace the primary artifact of the project.
> >> >> 2) attach an artifact with the user's choice of artifactId and
> >> classifier.
> >> >> 3) just drop a file someplace.
> >> >>
> >> >> In modes (1) and (2), it's also reasonable for the user to control
> the
> >> >> filename in the output directory, since every other plugin seems to
> >> >> allow that.
> >> >>
> >> >> So, what do people think of the following:
> >> >>
> >> >> Four parameters:
> >> >>
> >> >> <attach>true/false</attach>
> >> >>
> >> >> <attachArtifact>
> >> >> <artifactId/>
> >> >> <classifier/>
> >> >> </attachArtifact>
> >> >>
> >> >> <outputDirectory/>
> >> >> <finalName/>
> >> >>
> >> >> This puts all the information about the attached result in one place.
> >> >> Shade is the only plugin I know that allows you to attach with your
> >> >> choice of artifactId.
> >> >>
> >> >> To replace the primary artifact, the user would write:
> >> >>
> >> >> <artifactId>${project.artifactId}</artifactId>
> >> >> <classifier/>
> >> >>
> >> >> The defaults would be:
> >> >>
> >> >> <attach>true</attach>
> >> >>
> >> >> <attachArtifactId>
> >> >> <artifactId>${project.artifactId}</artifactId>
> >> >> <classifier>shaded</classifier>
> >> >> </attachArtifactId>
> >> >>
> >> >> <outputDirectory>${project.buildDirectory}</outputDirectory>
> >> >>
> >> >>
> >> >>
> >>
> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Shade and it's many options for controlling output
Posted by Benson Margulies <bi...@gmail.com>.
Anders,
I'm willing to go on a history expedition to see who added the
feature. The MavenProjectHelper API suports this feature, let alone
the naked MavenProject API.
On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <an...@hammar.net> wrote:
>> > How would you attach an artifact with a DIFFERENT artifactId than the
>> > project? It doesn't make sense.
>>
>> This is *already* a feature of the plugin. I didn't invent it, I'm
>> just trying to clean up how your configure it.
>>
>
> Why would you try to clean up how to configure something that doesn't make
> sense and is plain wrong? Maven is about best-practices and we should help
> people do the right thing.
>
> And btw, finalName should be nuked out of the Maven world. :-)
>
> /Anders
>
>
>>
>>
>>
>> >
>> > I would vote for doing changes that make it impossible to use the plugin
>> as
>> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
>> > think that the possibilities to alter the final name of the built
>> artifact
>> > fools people into thinking that you can specify the name of the artifact.
>> > You migth be able to specify the name of the build file in the build
>> > folder, but that's not something you should create a build solution
>> around.
>>
>> Well, finalName in the pom itself has this effect on the main
>> artifact, so, for better or worse, people build things that depend on
>> it all the time. *I* build things that depend on the use of the pom
>> element to flush version numbers from war files.
>>
>> So I, personally, am not comfortable with flushing finalName from the
>> picture.
>>
>>
>> >
>> > /Anders
>> >
>> >
>> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <bimargulies@gmail.com
>> >wrote:
>> >
>> >> Shade has a collection of related parameters for controlling where the
>> >> results end up. To me, they feel like a collection of individual items
>> >> that are fairly confusing to the reader of the documentation.
>> >>
>> >> Since I'm planning to bump the major version and change the behavior,
>> >> I'd like to consider rationalizing all of them.
>> >>
>> >> It seems to me that there are, in fact, three modes of operation:
>> >>
>> >> 1) replace the primary artifact of the project.
>> >> 2) attach an artifact with the user's choice of artifactId and
>> classifier.
>> >> 3) just drop a file someplace.
>> >>
>> >> In modes (1) and (2), it's also reasonable for the user to control the
>> >> filename in the output directory, since every other plugin seems to
>> >> allow that.
>> >>
>> >> So, what do people think of the following:
>> >>
>> >> Four parameters:
>> >>
>> >> <attach>true/false</attach>
>> >>
>> >> <attachArtifact>
>> >> <artifactId/>
>> >> <classifier/>
>> >> </attachArtifact>
>> >>
>> >> <outputDirectory/>
>> >> <finalName/>
>> >>
>> >> This puts all the information about the attached result in one place.
>> >> Shade is the only plugin I know that allows you to attach with your
>> >> choice of artifactId.
>> >>
>> >> To replace the primary artifact, the user would write:
>> >>
>> >> <artifactId>${project.artifactId}</artifactId>
>> >> <classifier/>
>> >>
>> >> The defaults would be:
>> >>
>> >> <attach>true</attach>
>> >>
>> >> <attachArtifactId>
>> >> <artifactId>${project.artifactId}</artifactId>
>> >> <classifier>shaded</classifier>
>> >> </attachArtifactId>
>> >>
>> >> <outputDirectory>${project.buildDirectory}</outputDirectory>
>> >>
>> >>
>> >>
>> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Anders Hammar <an...@hammar.net>.
> > How would you attach an artifact with a DIFFERENT artifactId than the
> > project? It doesn't make sense.
>
> This is *already* a feature of the plugin. I didn't invent it, I'm
> just trying to clean up how your configure it.
>
Why would you try to clean up how to configure something that doesn't make
sense and is plain wrong? Maven is about best-practices and we should help
people do the right thing.
And btw, finalName should be nuked out of the Maven world. :-)
/Anders
>
>
>
> >
> > I would vote for doing changes that make it impossible to use the plugin
> as
> > I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
> > think that the possibilities to alter the final name of the built
> artifact
> > fools people into thinking that you can specify the name of the artifact.
> > You migth be able to specify the name of the build file in the build
> > folder, but that's not something you should create a build solution
> around.
>
> Well, finalName in the pom itself has this effect on the main
> artifact, so, for better or worse, people build things that depend on
> it all the time. *I* build things that depend on the use of the pom
> element to flush version numbers from war files.
>
> So I, personally, am not comfortable with flushing finalName from the
> picture.
>
>
> >
> > /Anders
> >
> >
> > On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
> >
> >> Shade has a collection of related parameters for controlling where the
> >> results end up. To me, they feel like a collection of individual items
> >> that are fairly confusing to the reader of the documentation.
> >>
> >> Since I'm planning to bump the major version and change the behavior,
> >> I'd like to consider rationalizing all of them.
> >>
> >> It seems to me that there are, in fact, three modes of operation:
> >>
> >> 1) replace the primary artifact of the project.
> >> 2) attach an artifact with the user's choice of artifactId and
> classifier.
> >> 3) just drop a file someplace.
> >>
> >> In modes (1) and (2), it's also reasonable for the user to control the
> >> filename in the output directory, since every other plugin seems to
> >> allow that.
> >>
> >> So, what do people think of the following:
> >>
> >> Four parameters:
> >>
> >> <attach>true/false</attach>
> >>
> >> <attachArtifact>
> >> <artifactId/>
> >> <classifier/>
> >> </attachArtifact>
> >>
> >> <outputDirectory/>
> >> <finalName/>
> >>
> >> This puts all the information about the attached result in one place.
> >> Shade is the only plugin I know that allows you to attach with your
> >> choice of artifactId.
> >>
> >> To replace the primary artifact, the user would write:
> >>
> >> <artifactId>${project.artifactId}</artifactId>
> >> <classifier/>
> >>
> >> The defaults would be:
> >>
> >> <attach>true</attach>
> >>
> >> <attachArtifactId>
> >> <artifactId>${project.artifactId}</artifactId>
> >> <classifier>shaded</classifier>
> >> </attachArtifactId>
> >>
> >> <outputDirectory>${project.buildDirectory}</outputDirectory>
> >>
> >>
> >>
> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Shade and it's many options for controlling output
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Nov 25, 2012 at 1:48 PM, Anders Hammar <an...@hammar.net> wrote:
> How would you attach an artifact with a DIFFERENT artifactId than the
> project? It doesn't make sense.
This is *already* a feature of the plugin. I didn't invent it, I'm
just trying to clean up how your configure it.
>
> I would vote for doing changes that make it impossible to use the plugin as
> I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
> think that the possibilities to alter the final name of the built artifact
> fools people into thinking that you can specify the name of the artifact.
> You migth be able to specify the name of the build file in the build
> folder, but that's not something you should create a build solution around.
Well, finalName in the pom itself has this effect on the main
artifact, so, for better or worse, people build things that depend on
it all the time. *I* build things that depend on the use of the pom
element to flush version numbers from war files.
So I, personally, am not comfortable with flushing finalName from the picture.
>
> /Anders
>
>
> On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> Shade has a collection of related parameters for controlling where the
>> results end up. To me, they feel like a collection of individual items
>> that are fairly confusing to the reader of the documentation.
>>
>> Since I'm planning to bump the major version and change the behavior,
>> I'd like to consider rationalizing all of them.
>>
>> It seems to me that there are, in fact, three modes of operation:
>>
>> 1) replace the primary artifact of the project.
>> 2) attach an artifact with the user's choice of artifactId and classifier.
>> 3) just drop a file someplace.
>>
>> In modes (1) and (2), it's also reasonable for the user to control the
>> filename in the output directory, since every other plugin seems to
>> allow that.
>>
>> So, what do people think of the following:
>>
>> Four parameters:
>>
>> <attach>true/false</attach>
>>
>> <attachArtifact>
>> <artifactId/>
>> <classifier/>
>> </attachArtifact>
>>
>> <outputDirectory/>
>> <finalName/>
>>
>> This puts all the information about the attached result in one place.
>> Shade is the only plugin I know that allows you to attach with your
>> choice of artifactId.
>>
>> To replace the primary artifact, the user would write:
>>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier/>
>>
>> The defaults would be:
>>
>> <attach>true</attach>
>>
>> <attachArtifactId>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier>shaded</classifier>
>> </attachArtifactId>
>>
>> <outputDirectory>${project.buildDirectory}</outputDirectory>
>>
>>
>> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Peter Janes <pj...@gmail.com>.
Anders Hammar <an...@hammar.net> wrote:
>> The Enunciate plugin "attaches" its own artifact with a unique
>artifactId.
>
>
>Do you have an example of this? I checked the docs (
>http://enunciate.codehaus.org/executables.html#maven) and I can't see
>this.
The install and deploy goals are what I was referring to.
>> I'm not sure of the implementation details, but it's got its own
>> install-artifact and deploy-artifact goals that do the work.
>
>
>Those just work the same way as install:install-file and
>deploy:deploy-file, which are not supposed to be bound a project's
>build
>lifecycle. At least that's how I read the plugin's documentation.
There's better documentation on the Codehaus wiki:
http://docs.codehaus.org/display/ENUNCIATE/Client-side+artifacts+and+Maven
"Instead of attaching the client-side artifacts to the project, a better solution would be to deploy the artifacts with their own (generated) pom" that doesn't include the project's dependencies (which is why the goals were added).
>/Anders
>
>
>> (Just to note that there's at least one other plugin doing something
>> similar, not making a claim that it's right or wrong to do so.)
>>
>> Anders Hammar <an...@hammar.net> wrote:
>>
>> How would you attach an artifact with a DIFFERENT artifactId than
>the
>>> project? It doesn't make sense.
>>>
>>> I would vote for doing changes that make it impossible to use the
>>> plugin as
>>> I-would-like-to-create-any-**file-the-way-i-used-to-with-**Ant
>solution.
>>> I
>>> think that the possibilities to alter the final name of the built
>>> artifact
>>> fools people into thinking that you can specify the name of the
>>> artifact.
>>> You migth be able to specify the name of the build file in the build
>>> folder, but that's not something you should create a build solution
>>> around.
>>>
>>> /Anders
>>>
>>>
>>> On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
>>> <bi...@gmail.com>wrote:
>>>
>>> Shade has a collection of related parameters for controlling where
>>>>
>>> the
>>>
>>>> results end up. To me, they feel like a collection of individual
>>>>
>>> items
>>>
>>>> that are fairly confusing to the reader of the documentation.
>>>>
>>>> Since I'm planning to bump the major version and change the
>behavior,
>>>> I'd like to consider rationalizing all of them.
>>>>
>>>> It seems to me that there are, in fact, three modes of operation:
>>>>
>>>> 1) replace the primary artifact of the project.
>>>> 2) attach an artifact with the user's choice of artifactId and
>>>>
>>> classifier.
>>>
>>>> 3) just drop a file someplace.
>>>>
>>>> In modes (1) and (2), it's also reasonable for the user to control
>>>>
>>> the
>>>
>>>> filename in the output directory, since every other plugin seems to
>>>> allow that.
>>>>
>>>> So, what do people think of the following:
>>>>
>>>> Four parameters:
>>>>
>>>> <attach>true/false</attach>
>>>>
>>>> <attachArtifact>
>>>> <artifactId/>
>>>> <classifier/>
>>>> </attachArtifact>
>>>>
>>>> <outputDirectory/>
>>>> <finalName/>
>>>>
>>>> This puts all the information about the attached result in one
>place.
>>>> Shade is the only plugin I know that allows you to attach with your
>>>> choice of artifactId.
>>>>
>>>> To replace the primary artifact, the user would write:
>>>>
>>>> <artifactId>${project.**artifactId}</artifactId>
>>>> <classifier/>
>>>>
>>>> The defaults would be:
>>>>
>>>> <attach>true</attach>
>>>>
>>>> <attachArtifactId>
>>>> <artifactId>${project.**artifactId}</artifactId>
>>>> <classifier>shaded</**classifier>
>>>> </attachArtifactId>
>>>>
>>>> <outputDirectory>${project.**buildDirectory}</**outputDirectory>
>>>>
>>>>
>>>>
>>>> <finalName>${attachArtifact.**artifactId}-${attachArtifact.**
>>> classifier}-${project.version}**.jar</finalName>
>>>
>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail:
>dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>> --
>> "Fighting a war is easy. Destroying is easy. Building a new world
>out of
>> what's left of the old, that is what's hard." —J. Michael
>Straczynski
>>
>>
>>
>>
>------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Stephen Connolly <st...@gmail.com>.
On 25 November 2012 22:14, Peter Janes <ma...@peterjanes.ca>wrote:
> Anders Hammar <an...@hammar.net> wrote:
>
>> The Enunciate plugin "attaches" its own artifact with a unique
>>>
>> artifactId.
>>
>>
>> Do you have an example of this? I checked the docs (
>> http://enunciate.codehaus.org/**executables.html#maven<http://enunciate.codehaus.org/executables.html#maven>)
>> and I can't see
>> this.
>>
>
> The install and deploy goals are what I was referring to.
>
>
> I'm not sure of the implementation details, but it's got its own
>>> install-artifact and deploy-artifact goals that do the work.
>>>
>>
>>
>> Those just work the same way as install:install-file and
>> deploy:deploy-file, which are not supposed to be bound a project's
>> build
>> lifecycle. At least that's how I read the plugin's documentation.
>>
>
> There's better documentation on the Codehaus wiki:
>
> http://docs.codehaus.org/**display/ENUNCIATE/Client-side+**
> artifacts+and+Maven<http://docs.codehaus.org/display/ENUNCIATE/Client-side+artifacts+and+Maven>
>
> "Instead of attaching the client-side artifacts to the project, a better
> solution would be to deploy the artifacts with their own (generated) pom"
> that doesn't include the project's dependencies (which is why the goals
> were added).
That screws up the reactor's build plan though... which turns it into a
completely shitty idea
>
>
>
> /Anders
>>
>>
>> (Just to note that there's at least one other plugin doing something
>>> similar, not making a claim that it's right or wrong to do so.)
>>>
>>> Anders Hammar <an...@hammar.net> wrote:
>>>
>>> How would you attach an artifact with a DIFFERENT artifactId than
>>>
>> the
>>
>>> project? It doesn't make sense.
>>>>
>>>> I would vote for doing changes that make it impossible to use the
>>>> plugin as
>>>> I-would-like-to-create-any-****file-the-way-i-used-to-with-****Ant
>>>>
>>> solution.
>>
>>> I
>>>> think that the possibilities to alter the final name of the built
>>>> artifact
>>>> fools people into thinking that you can specify the name of the
>>>> artifact.
>>>> You migth be able to specify the name of the build file in the build
>>>> folder, but that's not something you should create a build solution
>>>> around.
>>>>
>>>> /Anders
>>>>
>>>>
>>>> On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
>>>> <bi...@gmail.com>wrote:
>>>>
>>>> Shade has a collection of related parameters for controlling where
>>>>
>>>>>
>>>>> the
>>>>
>>>> results end up. To me, they feel like a collection of individual
>>>>>
>>>>> items
>>>>
>>>> that are fairly confusing to the reader of the documentation.
>>>>>
>>>>> Since I'm planning to bump the major version and change the
>>>>>
>>>> behavior,
>>
>>> I'd like to consider rationalizing all of them.
>>>>>
>>>>> It seems to me that there are, in fact, three modes of operation:
>>>>>
>>>>> 1) replace the primary artifact of the project.
>>>>> 2) attach an artifact with the user's choice of artifactId and
>>>>>
>>>>> classifier.
>>>>
>>>> 3) just drop a file someplace.
>>>>>
>>>>> In modes (1) and (2), it's also reasonable for the user to control
>>>>>
>>>>> the
>>>>
>>>> filename in the output directory, since every other plugin seems to
>>>>> allow that.
>>>>>
>>>>> So, what do people think of the following:
>>>>>
>>>>> Four parameters:
>>>>>
>>>>> <attach>true/false</attach>
>>>>>
>>>>> <attachArtifact>
>>>>> <artifactId/>
>>>>> <classifier/>
>>>>> </attachArtifact>
>>>>>
>>>>> <outputDirectory/>
>>>>> <finalName/>
>>>>>
>>>>> This puts all the information about the attached result in one
>>>>>
>>>> place.
>>
>>> Shade is the only plugin I know that allows you to attach with your
>>>>> choice of artifactId.
>>>>>
>>>>> To replace the primary artifact, the user would write:
>>>>>
>>>>> <artifactId>${project.****artifactId}</artifactId>
>>>>> <classifier/>
>>>>>
>>>>> The defaults would be:
>>>>>
>>>>> <attach>true</attach>
>>>>>
>>>>> <attachArtifactId>
>>>>> <artifactId>${project.****artifactId}</artifactId>
>>>>> <classifier>shaded</****classifier>
>>>>> </attachArtifactId>
>>>>>
>>>>> <outputDirectory>${project.****buildDirectory}</****outputDirectory>
>>>>>
>>>>>
>>>>>
>>>>> <finalName>${attachArtifact.****artifactId}-${attachArtifact.****
>>>>>
>>>> classifier}-${project.version}****.jar</finalName>
>>>>
>>>>
>>>> ------------------------------****----------------------------**--**
>>>>> ---------
>>>>> To unsubscribe, e-mail:
>>>>>
>>>> dev-unsubscribe@maven.apache.****org<de...@maven.apache.org>
>> >
>>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>> "Fighting a war is easy. Destroying is easy. Building a new world
>>>
>> out of
>>
>>> what's left of the old, that is what's hard." —J. Michael
>>>
>> Straczynski
>>
>>>
>>>
>>>
>>>
>>> ------------------------------****----------------------------**
>> --**---------
>>
>>> To unsubscribe, e-mail:
>>>
>> dev-unsubscribe@maven.apache.****org<de...@maven.apache.org>
>> >
>>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
> --
> "Fighting a war is easy. Destroying is easy. Building a new world out of
> what's left of the old, that is what's hard." —J. Michael Straczynski
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Shade and it's many options for controlling output
Posted by Peter Janes <ma...@peterjanes.ca>.
Anders Hammar <an...@hammar.net> wrote:
>> The Enunciate plugin "attaches" its own artifact with a unique
>artifactId.
>
>
>Do you have an example of this? I checked the docs (
>http://enunciate.codehaus.org/executables.html#maven) and I can't see
>this.
The install and deploy goals are what I was referring to.
>> I'm not sure of the implementation details, but it's got its own
>> install-artifact and deploy-artifact goals that do the work.
>
>
>Those just work the same way as install:install-file and
>deploy:deploy-file, which are not supposed to be bound a project's
>build
>lifecycle. At least that's how I read the plugin's documentation.
There's better documentation on the Codehaus wiki:
http://docs.codehaus.org/display/ENUNCIATE/Client-side+artifacts+and+Maven
"Instead of attaching the client-side artifacts to the project, a better
solution would be to deploy the artifacts with their own (generated) pom" that
doesn't include the project's dependencies (which is why the goals were added).
>/Anders
>
>
>> (Just to note that there's at least one other plugin doing something
>> similar, not making a claim that it's right or wrong to do so.)
>>
>> Anders Hammar <an...@hammar.net> wrote:
>>
>> How would you attach an artifact with a DIFFERENT artifactId than
>the
>>> project? It doesn't make sense.
>>>
>>> I would vote for doing changes that make it impossible to use the
>>> plugin as
>>> I-would-like-to-create-any-**file-the-way-i-used-to-with-**Ant
>solution.
>>> I
>>> think that the possibilities to alter the final name of the built
>>> artifact
>>> fools people into thinking that you can specify the name of the
>>> artifact.
>>> You migth be able to specify the name of the build file in the build
>>> folder, but that's not something you should create a build solution
>>> around.
>>>
>>> /Anders
>>>
>>>
>>> On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
>>> <bi...@gmail.com>wrote:
>>>
>>> Shade has a collection of related parameters for controlling where
>>>>
>>> the
>>>
>>>> results end up. To me, they feel like a collection of individual
>>>>
>>> items
>>>
>>>> that are fairly confusing to the reader of the documentation.
>>>>
>>>> Since I'm planning to bump the major version and change the
>behavior,
>>>> I'd like to consider rationalizing all of them.
>>>>
>>>> It seems to me that there are, in fact, three modes of operation:
>>>>
>>>> 1) replace the primary artifact of the project.
>>>> 2) attach an artifact with the user's choice of artifactId and
>>>>
>>> classifier.
>>>
>>>> 3) just drop a file someplace.
>>>>
>>>> In modes (1) and (2), it's also reasonable for the user to control
>>>>
>>> the
>>>
>>>> filename in the output directory, since every other plugin seems to
>>>> allow that.
>>>>
>>>> So, what do people think of the following:
>>>>
>>>> Four parameters:
>>>>
>>>> <attach>true/false</attach>
>>>>
>>>> <attachArtifact>
>>>> <artifactId/>
>>>> <classifier/>
>>>> </attachArtifact>
>>>>
>>>> <outputDirectory/>
>>>> <finalName/>
>>>>
>>>> This puts all the information about the attached result in one
>place.
>>>> Shade is the only plugin I know that allows you to attach with your
>>>> choice of artifactId.
>>>>
>>>> To replace the primary artifact, the user would write:
>>>>
>>>> <artifactId>${project.**artifactId}</artifactId>
>>>> <classifier/>
>>>>
>>>> The defaults would be:
>>>>
>>>> <attach>true</attach>
>>>>
>>>> <attachArtifactId>
>>>> <artifactId>${project.**artifactId}</artifactId>
>>>> <classifier>shaded</**classifier>
>>>> </attachArtifactId>
>>>>
>>>> <outputDirectory>${project.**buildDirectory}</**outputDirectory>
>>>>
>>>>
>>>>
>>>> <finalName>${attachArtifact.**artifactId}-${attachArtifact.**
>>> classifier}-${project.version}**.jar</finalName>
>>>
>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail:
>dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>> --
>> "Fighting a war is easy. Destroying is easy. Building a new world
>out of
>> what's left of the old, that is what's hard." —J. Michael
>Straczynski
>>
>>
>>
>>
>------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
--
"Fighting a war is easy. Destroying is easy. Building a new world out of
what's left of the old, that is what's hard." —J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Anders Hammar <an...@hammar.net>.
> The Enunciate plugin "attaches" its own artifact with a unique artifactId.
Do you have an example of this? I checked the docs (
http://enunciate.codehaus.org/executables.html#maven) and I can't see this.
> I'm not sure of the implementation details, but it's got its own
> install-artifact and deploy-artifact goals that do the work.
Those just work the same way as install:install-file and
deploy:deploy-file, which are not supposed to be bound a project's build
lifecycle. At least that's how I read the plugin's documentation.
/Anders
> (Just to note that there's at least one other plugin doing something
> similar, not making a claim that it's right or wrong to do so.)
>
> Anders Hammar <an...@hammar.net> wrote:
>
> How would you attach an artifact with a DIFFERENT artifactId than the
>> project? It doesn't make sense.
>>
>> I would vote for doing changes that make it impossible to use the
>> plugin as
>> I-would-like-to-create-any-**file-the-way-i-used-to-with-**Ant solution.
>> I
>> think that the possibilities to alter the final name of the built
>> artifact
>> fools people into thinking that you can specify the name of the
>> artifact.
>> You migth be able to specify the name of the build file in the build
>> folder, but that's not something you should create a build solution
>> around.
>>
>> /Anders
>>
>>
>> On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
>> <bi...@gmail.com>wrote:
>>
>> Shade has a collection of related parameters for controlling where
>>>
>> the
>>
>>> results end up. To me, they feel like a collection of individual
>>>
>> items
>>
>>> that are fairly confusing to the reader of the documentation.
>>>
>>> Since I'm planning to bump the major version and change the behavior,
>>> I'd like to consider rationalizing all of them.
>>>
>>> It seems to me that there are, in fact, three modes of operation:
>>>
>>> 1) replace the primary artifact of the project.
>>> 2) attach an artifact with the user's choice of artifactId and
>>>
>> classifier.
>>
>>> 3) just drop a file someplace.
>>>
>>> In modes (1) and (2), it's also reasonable for the user to control
>>>
>> the
>>
>>> filename in the output directory, since every other plugin seems to
>>> allow that.
>>>
>>> So, what do people think of the following:
>>>
>>> Four parameters:
>>>
>>> <attach>true/false</attach>
>>>
>>> <attachArtifact>
>>> <artifactId/>
>>> <classifier/>
>>> </attachArtifact>
>>>
>>> <outputDirectory/>
>>> <finalName/>
>>>
>>> This puts all the information about the attached result in one place.
>>> Shade is the only plugin I know that allows you to attach with your
>>> choice of artifactId.
>>>
>>> To replace the primary artifact, the user would write:
>>>
>>> <artifactId>${project.**artifactId}</artifactId>
>>> <classifier/>
>>>
>>> The defaults would be:
>>>
>>> <attach>true</attach>
>>>
>>> <attachArtifactId>
>>> <artifactId>${project.**artifactId}</artifactId>
>>> <classifier>shaded</**classifier>
>>> </attachArtifactId>
>>>
>>> <outputDirectory>${project.**buildDirectory}</**outputDirectory>
>>>
>>>
>>>
>>> <finalName>${attachArtifact.**artifactId}-${attachArtifact.**
>> classifier}-${project.version}**.jar</finalName>
>>
>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
> --
> "Fighting a war is easy. Destroying is easy. Building a new world out of
> what's left of the old, that is what's hard." —J. Michael Straczynski
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Shade and it's many options for controlling output
Posted by Peter Janes <ma...@peterjanes.ca>.
The Enunciate plugin "attaches" its own artifact with a unique artifactId.
I'm not sure of the implementation details, but it's got its own
install-artifact and deploy-artifact goals that do the work. (Just to note
that there's at least one other plugin doing something similar, not making a
claim that it's right or wrong to do so.)
Anders Hammar <an...@hammar.net> wrote:
>How would you attach an artifact with a DIFFERENT artifactId than the
>project? It doesn't make sense.
>
>I would vote for doing changes that make it impossible to use the
>plugin as
>I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
>think that the possibilities to alter the final name of the built
>artifact
>fools people into thinking that you can specify the name of the
>artifact.
>You migth be able to specify the name of the build file in the build
>folder, but that's not something you should create a build solution
>around.
>
>/Anders
>
>
>On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
><bi...@gmail.com>wrote:
>
>> Shade has a collection of related parameters for controlling where
>the
>> results end up. To me, they feel like a collection of individual
>items
>> that are fairly confusing to the reader of the documentation.
>>
>> Since I'm planning to bump the major version and change the behavior,
>> I'd like to consider rationalizing all of them.
>>
>> It seems to me that there are, in fact, three modes of operation:
>>
>> 1) replace the primary artifact of the project.
>> 2) attach an artifact with the user's choice of artifactId and
>classifier.
>> 3) just drop a file someplace.
>>
>> In modes (1) and (2), it's also reasonable for the user to control
>the
>> filename in the output directory, since every other plugin seems to
>> allow that.
>>
>> So, what do people think of the following:
>>
>> Four parameters:
>>
>> <attach>true/false</attach>
>>
>> <attachArtifact>
>> <artifactId/>
>> <classifier/>
>> </attachArtifact>
>>
>> <outputDirectory/>
>> <finalName/>
>>
>> This puts all the information about the attached result in one place.
>> Shade is the only plugin I know that allows you to attach with your
>> choice of artifactId.
>>
>> To replace the primary artifact, the user would write:
>>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier/>
>>
>> The defaults would be:
>>
>> <attach>true</attach>
>>
>> <attachArtifactId>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier>shaded</classifier>
>> </attachArtifactId>
>>
>> <outputDirectory>${project.buildDirectory}</outputDirectory>
>>
>>
>>
><finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
--
"Fighting a war is easy. Destroying is easy. Building a new world out of
what's left of the old, that is what's hard." —J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Peter Janes <pj...@gmail.com>.
The Enunciate plugin "attaches" its own artifact with a unique artifactId. I'm not sure of the implementation details, but it's got its own install-artifact and deploy-artifact goals that do the work. (Just to note that there's at least one other plugin doing something similar, not to make a claim that it's right or wrong to do so.)
Anders Hammar <an...@hammar.net> wrote:
>How would you attach an artifact with a DIFFERENT artifactId than the
>project? It doesn't make sense.
>
>I would vote for doing changes that make it impossible to use the
>plugin as
>I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
>think that the possibilities to alter the final name of the built
>artifact
>fools people into thinking that you can specify the name of the
>artifact.
>You migth be able to specify the name of the build file in the build
>folder, but that's not something you should create a build solution
>around.
>
>/Anders
>
>
>On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
><bi...@gmail.com>wrote:
>
>> Shade has a collection of related parameters for controlling where
>the
>> results end up. To me, they feel like a collection of individual
>items
>> that are fairly confusing to the reader of the documentation.
>>
>> Since I'm planning to bump the major version and change the behavior,
>> I'd like to consider rationalizing all of them.
>>
>> It seems to me that there are, in fact, three modes of operation:
>>
>> 1) replace the primary artifact of the project.
>> 2) attach an artifact with the user's choice of artifactId and
>classifier.
>> 3) just drop a file someplace.
>>
>> In modes (1) and (2), it's also reasonable for the user to control
>the
>> filename in the output directory, since every other plugin seems to
>> allow that.
>>
>> So, what do people think of the following:
>>
>> Four parameters:
>>
>> <attach>true/false</attach>
>>
>> <attachArtifact>
>> <artifactId/>
>> <classifier/>
>> </attachArtifact>
>>
>> <outputDirectory/>
>> <finalName/>
>>
>> This puts all the information about the attached result in one place.
>> Shade is the only plugin I know that allows you to attach with your
>> choice of artifactId.
>>
>> To replace the primary artifact, the user would write:
>>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier/>
>>
>> The defaults would be:
>>
>> <attach>true</attach>
>>
>> <attachArtifactId>
>> <artifactId>${project.artifactId}</artifactId>
>> <classifier>shaded</classifier>
>> </attachArtifactId>
>>
>> <outputDirectory>${project.buildDirectory}</outputDirectory>
>>
>>
>>
><finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Shade and it's many options for controlling output
Posted by Anders Hammar <an...@hammar.net>.
How would you attach an artifact with a DIFFERENT artifactId than the
project? It doesn't make sense.
I would vote for doing changes that make it impossible to use the plugin as
I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I
think that the possibilities to alter the final name of the built artifact
fools people into thinking that you can specify the name of the artifact.
You migth be able to specify the name of the build file in the build
folder, but that's not something you should create a build solution around.
/Anders
On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <bi...@gmail.com>wrote:
> Shade has a collection of related parameters for controlling where the
> results end up. To me, they feel like a collection of individual items
> that are fairly confusing to the reader of the documentation.
>
> Since I'm planning to bump the major version and change the behavior,
> I'd like to consider rationalizing all of them.
>
> It seems to me that there are, in fact, three modes of operation:
>
> 1) replace the primary artifact of the project.
> 2) attach an artifact with the user's choice of artifactId and classifier.
> 3) just drop a file someplace.
>
> In modes (1) and (2), it's also reasonable for the user to control the
> filename in the output directory, since every other plugin seems to
> allow that.
>
> So, what do people think of the following:
>
> Four parameters:
>
> <attach>true/false</attach>
>
> <attachArtifact>
> <artifactId/>
> <classifier/>
> </attachArtifact>
>
> <outputDirectory/>
> <finalName/>
>
> This puts all the information about the attached result in one place.
> Shade is the only plugin I know that allows you to attach with your
> choice of artifactId.
>
> To replace the primary artifact, the user would write:
>
> <artifactId>${project.artifactId}</artifactId>
> <classifier/>
>
> The defaults would be:
>
> <attach>true</attach>
>
> <attachArtifactId>
> <artifactId>${project.artifactId}</artifactId>
> <classifier>shaded</classifier>
> </attachArtifactId>
>
> <outputDirectory>${project.buildDirectory}</outputDirectory>
>
>
> <finalName>${attachArtifact.artifactId}-${attachArtifact.classifier}-${project.version}.jar</finalName>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>