I think you could make 1 and 2: You can do 1 (having one build per module) because it will enforce you to separate your modules which will simplify maintenance (a monolithic application is more difficult to maintain). But still doing 2 by placing your 'private' jars into a separate repository (specific to the project), and place your 'public' wars and ears on a public repository.
Gilles > -----Original Message----- > From: Scott Goldstein [mailto:[EMAIL PROTECTED] > Sent: mardi 17 avril 2007 2:43 > To: [email protected] > Subject: Use Case Question > > I have a complex product for which I'm trying to design a build system. > The product consists of multiple web applications as well as libraries > shared between those web applications. Ideally, I'd like to treat the > entire product as an ivy module with multiple artifacts (installers, some > third party api libraries, etc.) versioned and distributed together. > However, given the complexity of the product, I'd like to break the bulid > down into multuple pieces, especially for the libraries which are shared > amongst web applications. So, here's my question: > > 1. Is it better for each library which is shared to also be Ivy modules > and have them published to the repository to be used by other parts of the > product build? My concern here is that these libraries really have no > meaning outside of the product. > > Or, > > 2. Is it better to treat these libraries in a special fashion? Perhaps > having them copied to a product only build directory and have them be > picked up by the various web applications there. To utilize Ivy > facilities, I would maybe create a file system resolver with set > useOrigin="true" for use by the web applications to find these files. > > The first options follows the one bulid->one build artifact pattern > enforced by Maven, but this causes some overhead that I'm not sure is > necessary. > > Any thoughts? > > Thanks for the input. > > Scott > > >
