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
