I've tried it to the extent possible, yes. I attach with a classifier "small" to indicate the obfuscated (and shrunken) jar. The maven war plugin will look at the MavenProject.getArtifacts() to pull in the scoped dependencies, but it doesn't look at MavenProject.getAttachedArtifacts(). There just isn't any hook there to get the plugin to process the attached artifact - best I can do is write it directly into WEB-INF/lib and let the packager pick it up.
So my proposal was to add a Boolean to the war plugin to tell it to include any attached jar artifacts. I could optionally add a classifier name, e.g. add only an attached artifact matching the artifactid of the project and with this classifier. Or a list of any arbitrary artifact ID strings which match attached artifacts... for my specific use case simply the Boolean will do. And similarly I want to make the same change in the maven shade plugin. The shade plugin is very focused on the primary artifact of the project, so for that I was thinking to just adding the Boolean and classifier - as Stephen points out, the attached artifact with classifier should have the same transitive dependencies anyway. The larger question is how to move generated artifacts from one plugin to another. The pushback I've gotten on these proposed changes to the plugins is that attachment isn't supposed to be used for that purpose - attachment is solely for putting artifacts into the repository, and not for passing newly generated artifacts between plugins. New feature perhaps? Idea being the notion of transient artifacts which only persist for the life of a maven session? Then other plugins in the same execution which potentially could use these transient artifacts could either automatically look for them or be configured to do so, like I suggested above for the war and shade plugins. The only difference between the transient and attached artifacts is that the transient wouldn't get persisted to a repository. And if you want to attach it, a plugin like the mojo buildhelper could have a goal to attach any (or specific) transient artifacts. If I'm talking crazy, please forgive me, school started today for my 2nd grader and I haven't had my coffee yet. :-) Thanks! -Richard -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, August 27, 2013 3:32 AM To: Maven Users List Subject: Re: artifact attached by plugin not appearing in subsequent plugins On Tuesday, 27 August 2013, Barrie Treloar wrote: > On 21 August 2013 00:42, Richard Sand <rs...@idfconnect.com > <javascript:;>> > wrote: > > Is there any merit to the idea of having a configuration option in > maven-war-plugin to include attached artifacts in the webapp in the > same way it includes dependent artifacts? > > The MavenProjectHelper.attachArtifact requires a type or classifier in > order to be used. > > The default artifact and the attached artifact are different > dependencies, and so you need to specify them twice for them to be > included in the webapp. > One for the default artifact and one for the attached artifact (which > has the type or classifier specified so that you can tell the > difference). > > I dont use the war plugin, but I specifying the dependency on the > attached artifact should mean that it appears in your war. And better still, since the obfuscated artifact *should* have the same transitive dependencies, it would be the one case where two artifacts from the same module would be ok. OTOH if obfuscation adds shade-like dependency reduction *then* it needs to get a separate GAV > > Have you tried this? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > <javascript:;> For additional commands, e-mail: > users-h...@maven.apache.org<javascript:;> > > -- Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org