Hi Steve, I use confs to do this too, but flipped from what you show below.
- runtime; everything that belongs in the war - compile; extends runtime and adds compile time deps - test; extends compile and adds test time deps ~Sent from my mobile device. Please pardon any oddities :-) On Jul 24, 2011, at 8:12 AM, Steve Prior <spr...@geekster.com> wrote: > I'm using Ivy to build libraries which can either be used from the command > line or incorporated into a webapp in a container such as Tomcat and am > trying to find an intelligent way to handle dependencies which need to be > excluded from the generated war file because they are supplied with Tomcat > itself. > > > Example: > > I've got project someLib which interacts with a MySQL database so it has a > dependency on the mysql java connector for the case when I launch a main > program in the library for command line use. > > I've also got project someWebApp which adds a web UI on top of the someLib > functionality. Since my standard Tomcat installation manages the MySQL > database connection the mysql java connector should not be built into the war > file deployed to Tomcat. Also, while I need the servlet library to be able > to compile my webapp, I certainly should not include that in the built war > file under any circumstances. > > It occurs to me that which jars are installed standard on the servers is a > site wide configuration and shouldn't really be the concern of the individual > projects. I was thinking of defining a war configuration which extends the > runtime configuration, but then excludes the artifacts which should not be > built in. > > Something along the general idea of this (though I don't know yet if placing > excludes is allowed here: > > <configurations > confmappingoverride="true" > defaultconfmapping="compile->compile(default); > runtime->runtime(default)" > > > <conf name="runtime" extends="compile" /> > > <conf name="war" extends = "runtime" > > <exclude org="com.mysql" name="mysql-connector-java" /> > </conf> > </configurations> > > I've gotta believe I'm not the first person to want to do this, are there any > best practices out there? Do I appear to be heading in the right direction? > > Thanks > Steve
