ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mochel" <>
Subject RE: Common Build Time only dependencies
Date Thu, 08 Feb 2007 14:35:28 GMT

Thank you all.

This set of choices clarified things perfectly.

Because I need to have the flexibility to change the build environment rapidly and in a way
that is documented (i.e. part of the project's dependency graph I will be going with easyproglife's
#2 choice.

Thanks Again,


-----Original Message-----
From: Gilles Scokart [] 
Sent: Thursday, February 08, 2007 3:11 AM
Subject: RE: Common Build Time only dependencies

Note that before choosing an approach or an other, you have to answer the
question : "What to do if a project try to use a different version of one of
the common dependencies?".  Every project might have a different answer to
that, and it will impact the solution you can take.


> -----Original Message-----
> From: easyproglife []
> Sent: jeudi 8 février 2007 9:03
> To:
> Subject: Re: Common Build Time only dependencies
> Hi Jim.
> I see a few options for you:
> 1. Even though ivy is a good tool, if your build tools doesn't change
> often,
> you can avoid using ivy at all for the build system itself. Just put those
> required jars in a common directory (e.g. under your home directory) and
> tell every build to include those jars in the classpath.
> You can still use ivy to manage dependencies of the projects themselves.
> But
> the build system not necessarily have to use ivy. It could simplify
> things.
> 2. If you do want to benefit from ivy even in the build system itself, you
> can write a standalone ivy.xml for the build system itself, not the one
> that
> each project has. In this ivy.xml specify your dependencies required for
> the
> build process. During build start, do a separate flow of resolve,
> cachepath
> or retrieve in order to get those jars. Then you can use ivy for the
> projects dependencies as usual.
> 3. To simplify the previous option, you can use "inline" mode in resolve
> and
> retrieve and hard-code the dependencies of the build system. The result is
> a
> lack of additional ivy.xml
> Note: I think retrieve is better than cachepath in this case for
> performance
> reasons. Unless your build-system dependencies getting updated recently,
> you
> can retrieve those jars once into some "lib" directory in a shared
> location,
> and things would be run faster.
> I hope this would help you get the best results from ivy.
> easyproglife.
> On 2/7/07, James Mochel <> wrote:
> >
> > Hey Folks,
> >
> > I am currently creating a new build system for my development team and
> > Ivy is a mainstay of it.
> >
> > I only have one problem so far: How do I ensure the inclusion of common
> > buildsystem dependencies.
> >
> > For example: our build system uses xdoclet and several other java tools
> > at build time and I don't want to include them as dependencies in the
> > ivy.xml file of every component. Is there anyway for me to reference a
> > common set of dependencies ?
> >
> > Thanks
> >
> > Jim Mochel
> >

View raw message