You certainly can use the configure() closure to wire up multiple projects to have identical aspects, but right now there is no way to inherit those characteristics from a dependedUpon project - similar to how the compile and runtime dependencies do not have to be explicitly defined for every downstream project.
-Spencer >________________________________ >From: Luke Daley <[email protected]> >To: [email protected] >Sent: Tuesday, October 4, 2011 6:43 AM >Subject: Re: [gradle-user] Re: War plugin evolution and overlays > > >On 04/10/2011, at 11:05 AM, davide.cavestro wrote: > >>> I'm not currently looking into addressing this - at least until I can >>> verify that making life potentially a bit more difficult for maven >>> deployment with multiple artifacts (i.e. jar and war both being added to >>> archives). >>> >> Certainly it could be a problem... on the other hand I guess - provided that >> publishing the war could be considered a not-so-strict requirement - the war >> artifact could be marked with an apposite classifier, while the jar could >> remain the main artifact (I suppose that should not be a real problem for >> maven users). > >I strongly recommend avoiding classifiers as much as possible. Classifiers >kind of work for providing metadata for a given artifact, but completely >breaks down for trying to publish variants. By metadata I mean things like >source jars, javadocs jars etc. You'll save yourself much pain by just using a >different artifactId for the jar and the war. > >> Also, even restricting the hypothesis only to project deps (hence not >> involving deps repositories) a convention for sharing resources between war >> enabled projects could be a great enhancement. >> I imagine a war plugin that simply adds some features to the Java or Groovy >> one, /letting unchanged their original output and logic/ adding only other >> output, conventions and logic, i.e. accessing the /webAppDir/ of relevant >> war projects to merge that resources with the current project ones, >> interpreting their deps with the right semantic (propagating provided deps >> the right way) and so on. > >I'm interested on what kind of cases can't be solved by using the DSL to apply >configuration to multiple projects as outlined in the previous email. I fully >expect that there may be cases, and we should explore them. > >-- >Luke Daley >Principal Engineer, Gradleware >http://gradleware.com > > >--------------------------------------------------------------------- >To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > >
