commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Maven Wish (was: Re: [jelly] Problems running unit tests?)
Date Mon, 08 Jul 2002 18:04:03 GMT


On 8 Jul 2002, Jason van Zyl wrote:

> > While I've got your attention, can I add a wish list item for Maven?
>
> Sure!
>
> > I'd
> > like to be able to override the declared dependency version in some
> > circumstances -- for example, I'm going to create a webapp that combines
> > lots of different JARs that all depend on (say) commons-beanutils.jar, and
> > I want to make sure that I can compile and test all the components against
> > a single named version of beanutils.
>
> So each of the individual projects that contribute a JAR to the WAR may
> use different versions of beanutils but you want to override this value
> where the onus is on you to make sure things work? Just making sure I
> understand. I don't think this would be problem and would certainly make
> sense for integrations like you're describing.
>

You've got it.  Basically, I don't want to just depend on our promises of
backwards compatibility -- I'd like to physically compile all of the
things that will go into the ultimate app against the same version of the
shared dependencies and let the compiler give me early warnings about some
of the potential problems.

In non-Mavenized builds, I accomplish this goal very simply, by overriding
the individual properties like "commons-beanutils.jar" in my
${user.home}/build.properties file.  It would be nice to have some similar
global override mechanism.

> > Since the webapp is all going to run
> > out of a single WAR file (and therefore share a single copy of the
> > beanutils JAR file), this is the only way I've got to ensure that I won't
> > get method mismatches at runtime caused by compiling different packages
> > against different versions of beanutils.
>
> Ok, that's a use case I'm sure many integrators will face. See what I
> can pop in. Are you going to test it when I'm done ;-)
>

Absolutely :-).

And, post-Struts-1.1-release, I'm going to evaluate switching Struts to
use Maven as well.  Like Turbine et. al., Struts (and applications built
on it) will run into this use case a lot, because Struts itself uses a
pile of commons components.


Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message