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, Jim -----Original Message----- From: Gilles Scokart [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 3:11 AM To: [email protected] 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. Gilles > -----Original Message----- > From: easyproglife [mailto:[EMAIL PROTECTED] > Sent: jeudi 8 février 2007 9:03 > To: [email protected] > 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 <[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 > >
