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 <and...@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 <bimargul...@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-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
