ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From easyproglife <>
Subject Re: Common Build Time only dependencies
Date Thu, 08 Feb 2007 08:02:47 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message