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"
rev="1.1.1"/>
* 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
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.
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?
Steve
