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

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:





no sub-objects.

On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies wrote:

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 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
sense and is plain wrong? Maven is about best-practices and we should
people do the right thing.

And btw, finalName should be nuked out of the Maven world. :-)


I would vote for doing changes that make it impossible to use the
I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution.
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
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

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


On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies <
Shade has a collection of related parameters for controlling where
results end up. To me, they feel like a collection of individual
that are fairly confusing to the reader of the documentation.

Since I'm planning to bump the major version and change the
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
3) just drop a file someplace.

In modes (1) and (2), it's also reasonable for the user to control
filename in the output directory, since every other plugin seems to
allow that.

So, what do people think of the following:

Four parameters:




This puts all the information about the attached result in one
Shade is the only plugin I know that allows you to attach with your
choice of artifactId.

To replace the primary artifact,

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 19 | next ›
Discussion Overview
groupdev @
postedNov 25, '12 at 3:56p
activeNov 25, '12 at 11:06p



site design / logo © 2021 Grokbase