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 <[EMAIL PROTECTED]> 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
