Quoting Joe Germuska <[EMAIL PROTECTED]>:
> Oh yeah, also I can't go back from having versioned JAR in my lib
> directories. I suspect that's a matter of taste too, but I'll take
> the overhead of pruning old JARs when new versions are deployed over
> the mystery of knowing which versions your apps depend on any day...
>
Interestingly, this touches on my single biggest frustration with Maven.
Professionally, I live in a world where there are some fairly large projects,
which integrate *lots* of open source projects (a very large number of
jakarta.apache.org and xml.apache.org subprojects are included). Many of these
open source projects have overlapping dependencies on several Jakarta Commons
packages -- not a surprise, those packages were *designed* for reuse. But
Maven (like many other build environments) encourages you to define the
specific version dependencies for each package you build independently. That's
not good enough for enterprise development.
All of the Ant build.xml files I care about include a line like this:
<property file="${user.home}/build.properties"/>
that lets me define the individual versions of *all* dependencies for *all*
projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build ***all*** of
the components that are going in to my overall exectable. I am *so* not
interested in dealing with runtime exceptions because different dependent
packages were compiled against different versions of the dependent libraries.
Can someone please help me understand how to do this with Maven? Without it,
I'm not planning to switch any of my personal or internal-to-Sun projects (even
if the Struts committers decide to switch Struts development itself).
> Joe
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
