Luke Daley-2 wrote: > > You'll save yourself much pain by just using a different artifactId for > the jar and the war. > you are right
Luke Daley-2 wrote: > > Would it be possible to use this kind of DSL approach to implement the > overlay instead of using project dependencies? It seems like it's going to > be simpler and no more verbose. > I've never used the http://gradle.org/current/docs/dsl/org.gradle.api.Project.html#org.gradle.api.Project:configure%28java.lang.Iterable,%20groovy.lang.Closure%29 Project.configure() before: it's straightforward and I have no evidence of cases that can't be solved by using the DSL to apply configuration to multiple projects. But this is the situation: we have a multi-project build that copes with some portion of web application organized indifferent projects: some could be merged into a single project, but others should remain separate (i.e. additional custom code and resources). To have a good integration with STS we have to use project dependencies (see the http://gradle.1045684.n5.nabble.com/Is-it-possible-to-elect-a-local-gradle-project-to-satisfy-other-projects-deps-tp4497854p4785691.html relative thread ). At this point publishing war artifacts is not needed, but we should still be able to merge (copy) contents from web app portions into a complete web application. Gradle is so flexible that we easily achieve merging using something like I'm just wondering if there could be a good convention to achieve this... some *standard behavior* that the war plugin (or another plugin) could implement. Stating that a war project by convention gets contents from other war projects/artifacts it depends upon could be a starting point. I think basically servlet 3 specs added support to http://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment web fragments to enhance pluggability, and it can also be enforced in terms of war overlays at build time. Cheers Davide Cheers Davide -- View this message in context: http://gradle.1045684.n5.nabble.com/War-plugin-evolution-and-overlays-tp4864964p4868301.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
