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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected] > >>> >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,
