You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Scott Goldstein <sg...@apache.org> on 2007/04/17 02:42:54 UTC

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
   
     



RE: Use Case Question

Posted by Gilles Scokart <gs...@gmail.com>.
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:sgoldstein@apache.org]
> Sent: mardi 17 avril 2007 2:43
> To: ivy-user@incubator.apache.org
> 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
> 
> 
>