commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Maven Wish (was: Re: [jelly] Problems running unit tests?)
Date Mon, 08 Jul 2002 18:18:53 GMT
On Mon, 2002-07-08 at 14:04, Craig R. McClanahan wrote:
> 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}/ file.  It would be nice to have some similar
> global override mechanism.

This is something where the 'reactor' might come in handy. The reactor
is going to be a mechanism that operates on 1..n projects in an
arbitrary fashion. You'll be able to use Jelly script and a workflow
semantics (yet to be decided, but Bob McWhirter is currently working on
a Zenplex sponsored effort to create a RETE based workflow engine) so
that you'll pretty much be able to do anything with a set of projects
i.e.a gump type build or glob a bunch of projects together to make a

So you would list a set of projects, you could build them, automate some
form of integration using Jelly script, run some tests, send some
reports, publish other reports, package things up on success, notify on
failure or start the process again. Whatever. I think CI is incredibly
important and it's lot easier doing integration work when projects are
unified. I'm hoping that Reactor will be key in prompting people to use

A very simple form of the reactor now works, but not good enough for
general consumption yet.

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

Cool. I think the b5 release of Maven will be the place things start to
work for people. The generated build.xml files and gump descriptors
should work and we're trying to make it as easy to use as possible.
Jelly has made a world of difference and I believe b5 will kick some
serious ass.

> Craig
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Jason van Zyl

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  -- Jacques Ellul, The Technological Society

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message