ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Prior <>
Subject Re: container supplied jars excluded in ivy
Date Tue, 26 Jul 2011 03:24:11 GMT
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.  Now here was a concession - I tend 
to have a minimal main class in my library projects which is used in development 
for initial testing and to have around as a little utility later, others would 
want runtime dependencies required for junit.  The totally pure thing would be 
to have that stuff which has a main() to be in a different project, so I'd 
actually never have code which might run in a container sharing ivy confs with 
code which might need command line runtime dependencies (the container driven 
code shouldn't include mysql or mail for example).  But doing so would be a pain 
for code which is a little small to deserve it's own project.

Plus you'd have to deal with two sets of runtime dependency additions: container 
based and non-container based:

My library project might use Hibernate, so now my library project ivy would have 
to deal with:

* common runtime dependencies:
    <dependency conf="runtime" org="org.apache.commons" name="commons-logging" 

* container managed dependencies
    -maybe nothing, this is when Tomcat supplies the MySQL connection)

* container doesn't manage dependencies
    - your local Tomcat isn't mnaging the mysql connection, so include it anyway

* junit
    - not running in a container so need mysql, and also need junit stuff

So you've got a library project which for compiles doesn't NEED to care whether 
it's running in a container or not now needing to provide configs for situations 
it shouldn't care about - that gets bad fast (guess how I found out).  This gets 
extra sticky when you start to deal with super libraries like Hibernate which 
provide more than one jar which you may work around by providing an ivy.xml for 
them which then needs to differentiate between compile and runtime (yes I ran 
into this).

So after having done it that way I come back around to my most recently proposed 

* 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.

So while I agree that dependencies should always be added and not taken away, in 
this casse I really think this is the better sacrifice (I like to code,hate to 
screw with ivy.xml files).

At all convinced?


View raw message