ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject RE: Use Case Question
Date Tue, 17 Apr 2007 06:50:05 GMT
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


> -----Original Message-----
> From: Scott Goldstein []
> Sent: mardi 17 avril 2007 2:43
> To:
> 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

View raw message