To me, adding a bunch of dependencies, only to later exclude them, seems a
little backward (and awkward). If war is not a superset of runtime or compile,
then I wouldn't make it extend them. I'd create a base config, which contains
the minimal intersection of dependencies, and then add deps shared by runtime
and war to minimal, and those only needed by runtime to it:
<conf name="war"
extends="minimal"
/>
<conf name="runtime"
extends="minimal"
/>
<dependency conf="runtime" org="javax.servlet" name="servlet-api"
rev="2.4"/>
<dependency conf="minimal" org="com.geekster" name="library.tvLib"
rev="latest.integration"/>
Thanks,
---
Kirby Files
Software Architect
Masergy Communications
kfi...@masergy.com
________________________________________
From: Steve Prior [spr...@geekster.com]
Sent: Monday, July 25, 2011 9:18 PM
To: ivy-user@ant.apache.org
Subject: Re: container supplied jars excluded in ivy
> Odd, for me the inverse is true. I need the most things on my classpath at
> test time [servlet spec, junit], fewer at compile [servlet spec], and fewest
> at run time [just my war].
>
> Here's the snippet of my configurations, and their mapping. I use
> externalized configuration so there's added confs for configuration and
> externalized WSDLs..
>
> <configurations
> defaultconfmapping="runtime->runtime(*);config->config(*);test->runtime(*);compile->runtime(*)">
>
> <conf name="config" description="LCFG configuration templates
> associated with this module"/>
> <conf name="wsdl" description="WSDLs associated with this module"/>
>
> <conf name="runtime" extends="config,wsdl" description="anything
> necessary to run; bundled into EAR/WAR"/>
> <conf name="compile" extends="runtime" visibility="private"
> description="anything necessary to compile"/>
> <conf name="test" extends="compile" visibility="private"
> description="anything needed to run unit tests"/>
> </configurations>
Those configs still seem odd to me because for example when using Hibernate
there are certainly fewer jars required to compile than run (logging for
example).
I thought about this war problem a lot and came up with:
defaultconfmapping="compile->compile(default);
runtime->runtime(default);
war->runtime(default)"
<conf name="war"
extends="runtime"
/>
Now I have removed all mention of a war configuration for everything that is not
actually a webapp (I tried it the other way and it was a mess). Here is one of
my new ivy.xml files:
<!DOCTYPE project>
<ivy-module version="2.0">
<info organisation="com.geekster" module="tv"/>
<configurations>
<include file="${ivy.settings.dir}/buildenv.ivy.configurations.xml"/>
</configurations>
<publications>
<artifact type="war" ext="war"/>
</publications>
<dependencies>
<dependency conf="compile" org="javax.servlet" name="servlet-api"
rev="2.4"/>
<dependency conf="compile" org="com.geekster" name="library.tvLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster" name="library.ajaxLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster"
name="library.hibernate_utils" rev="latest.integration"/>
<dependency conf="compile" org="org.hibernate" name="hibernate3"
rev="3.2.2.ga"/>
<dependency conf="compile" org="com.geekster" name="library.java_util"
rev="latest.integration"/>
<exclude conf="war" org="com.mysql" module="mysql-connector-java"/>
<exclude conf="war" org="javax.activation" module="activation"/>
<exclude conf="war" org="javax.mail" module="mail"/>
<exclude conf="war" org="javax.servlet" module="jsp-api" />
<exclude conf="war" org="javax.servlet" module="servlet-api" />
</dependencies>
</ivy-module>
The new thing for me is to add the block of excludes which strip out all of the
shared jars on my local Tomcat installations, but do so without needing to know
which dependency (if at all) brought them into the mix - this was a new trick I
just found out.
Now I REALLY wanted to be even a little more clever and put that block of
excludes in a file in my ivy.settings.dir and include them into place, but it
turns out the include directive isn't allowed there (nuts). That would have
been an especially deluxe solution since I could have had different include
files for different server setups in my environment (Tomcat, JBoss, whatever).
But at least I can standardize this block and rubber stamp it on my web project
ivy.xml's without having to think about it.
If anyone has some more fantastic tweaks I'm all EARs...
Steve
