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