Luke Daley-2 wrote: > > Do you mind recapping where we are with this? I've lost the context I'm > afraid and am not grasping it from the previous messages. > Recapping:
*Short version* On projects using war plugin, we need some special handling of dependencies on war artifacts in order to produce a merged war. In other words: it would be great to have the web application resources to be handled just like the Java classpath, with dependencies support. This special handling should be properly exposed through the tooling api for IDE integration. *Verbose version* When you build a library your main goal is - more or less - to produce a main jar, made up of bytecode bundled with some resources. When you build a standalone java application maybe you want to package the main jar and its dependencies into a compressed archive. Here we use configuration dependencies to provide additional jars to the compiler classpath or to package them to be in the classpath at runtime. When you build a web application your main goal is to produce a war, made up of: 1. web application resources (such as html, jsp pages, gwt compiler output and so on) 2. bytecode and resources packaged into WEB-INF/classes and WEB-INF/lib If you have designed your web application to be easily customized (cause you prefer composing projects instead of using scm branches) then you want to repackage the standard web application for customer X with some additional html, some additional code, and doing some additional ioc. *It would be good to use configuration dependencies to declare the relationship between the custom web application and the standard one, in order to obtain - for the custom webapp - a war that consists of the merge of standard webapp contents and new ones*. This could be considered standard behavior. In fact Maven supports this kind of merge under the name /war overlay/. Just to clarify: I've never used this maven feature... I've never used maven seriously, cause I chose gradle :-) Maven directly uses /dependencies on war artifacts/ to produce a new war eventually based on some inclusion/exclusion patterns. You can find some easy samples at http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html *On IDE integration* At this point I'd like to focus on the *development time counterpart need*: if the war plugin supported the concept of dependencies between webapp resources, this concept could be used not only by the WAR task to create the resulting war, but also by the tooling API in order to enable the client code to use such dependencies for other purposes: for instance, the STS Gradle Support could map these kind of dependencies to compose the /WebContent/ folder of an Eclipse web project in order to produce a /modular/ web application. There's room enough to further elaborate some additional details. Please let me know if you are interested. Cheers Davide -- View this message in context: http://gradle.1045684.n5.nabble.com/War-plugin-evolution-and-overlays-tp4864964p4916958.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
