Steve,
Steve Prior wrote on 07/25/2011 11:24 PM:
On 7/25/2011 10:39 PM, Kirby Files wrote:
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"/>
I considered that and agree with you at a philosophical level, but it didn't
work when it scaled up. I had "library" projects which used hibernate and then
webapps projects which would depend on them.
[...]
So after having done it that way I come back around to my most recently proposed
method:
* library code provides compile and runtime confs, and the runtime conf provides
anything that might be needed at runtime, container or not.
* the actual webapp project project just needs to deal with compile and runtime
configs from the library projects, and it's ONLY that last webapp ivy.xml which
needs to have ANY concept of how your local Tomcat/container servers are loaded
up with any shared libs or managed resources.
At all convinced?
I can see how, given your situation, using excludes is a more general
solution. I guess I'm fortunate not to be in that situation, though
I'm glad to learn of the per-conf exclude at the <dependencies> level;
I wasn't previously aware it could be used like that.
Thanks,
---
Kirby Files
Software Architect
Masergy Communications, Inc.
kfi...@masergy.com
