Working on multiple dependant projects at once

[Ma...@bpsinc.com]

I work at a place where we have a "product" and then we have multiple
"client" customization projects that sit on top (one 'customization' per
client).

 

The theory is, the "product" is developed by one team, and the
customizations are done by other teams, and thus in theory the product
team should have one ivy file, and the client teams would each have
their own, that simply treats the product as a dependency.

 

In practice, however, client teams are always working on product at the
same time (in order to fix bugs, add customization points, enhance
product features etc).

 

So what I've set up a standard ivy/ant for the product, but for clients
I have an extended build that builds the core product and the client
customizations.  In order to do this, I use the core ivy file, AND a
second client ivy file that has all the dependencies of the client but
does not depend on the core (since I'm building it at the same time).  

 

However, having two ivy files in a single build is problematic because:

-most of my client dependencies exist in the core product, and I have to
be careful to ensure I keep version numbers in sync.

-when I use ivyde, the client project and core project both load their
dependencies, even if they're the same jar, this is particularly
problematic if the versions have resolved differently.

 

Anyone have a better idea on how to do this?

 

Also, I'm only using ivy for build time dependency management, I'm not
using it for deployment or pom/ivy file generation (at least not yet),
so that does not need to factor into any suggestions.

 

 

 

RE: Working on multiple dependant projects at once

[Ma...@bpsinc.com]

Sorry, I guess I was not clear.  That's what I am doing.

Except to speed things up, my "client-a" builds both core and client,
"re-extracting" the core for every little change is what I'm trying to
avoid, i.e., if I just change a JSP in my core project, the  build just
copies that one file into my deploy folder.  I don't want to pay the
price of re-archiving the core project, stuffing it in the local repo,
pulling it out of the local repo, unzipping and then checking all files
to see which one(s)
actually need updating.  (If my core project was just a jar, that'd be
ok, but it's an entire base web app, that then gets "customized").

I am putting the core dependencies (ivy) into a local repo, so the
client build can see them, for the purposes of classpaths and library
deployment.

However, this gives me two problems

1) I have to "double maintain" the version numbers of any library
I have in both core and client. (I could just "assume" that the
libraries
The client build depends on are in the core project, e.g., if my client
project needs "commons-lang", I could assume that my core project has it
rather than explicitly declare my dependence on it, but that seems
equally icky).
2) I parse the core dependencies twice during a standard build cycle,
once for the "core" part, and once when the "core" dependencies are
analyzed for the client build.

I think the root of the problem is that the client project is not so
much dependant on the core project, as it _is_ the core project, plus a
bunch of hacks.

Right now, I'm tempted to find some way to have the client build "merge"
the core ivy.xml in to the client (xslt??) ivy.xml, and then treat the
whole
thing as a single super project.  Since that's logically what I'm doing,
it seems the most elegant.



-----Original Message-----
From: Vladimir Ritz Bossicard [mailto:vladimir@ritz-bossicard.com] 
Sent: Monday, February 08, 2010 9:25 AM
To: ivy-user@ant.apache.org
Subject: Re: Working on multiple dependant projects at once

Mark,

To try to solve this problem, I would distinguish between publishing the

"product" onto a local vs. central repository.  A local repository is 
similar to a central one, but is just sitting on someone's HD.

For this to work, the ivysettings.xml must first check the local 
repository and then the shared one.

The work flow would then be:

   1. developers check-out the "product" and "client-A" projects
locally.
   2. to speed up the developement, "client-A" would depend (in Eclipse)

from "product"
   3. the developers make modifications to both projects
   4. he publishes the (modified) "product" project onto his local 
repository
   5. when building the "client-A" application, the version from the 
local repository (should) will be downloaded
   6. when everything is fine, the developer checks in the changes for 
the "product" project and ideally triggers a central job (e.g. in 
Hudson) to publish the "product" jars into the central repository.

Could you follow me?

-Vladimir

> I work at a place where we have a "product" and then we have multiple
> "client" customization projects that sit on top (one 'customization'
per
> client).
>
>  
>
> The theory is, the "product" is developed by one team, and the
> customizations are done by other teams, and thus in theory the product
> team should have one ivy file, and the client teams would each have
> their own, that simply treats the product as a dependency.
>
>  
>
> In practice, however, client teams are always working on product at
the
> same time (in order to fix bugs, add customization points, enhance
> product features etc).
>
>  
>
> So what I've set up a standard ivy/ant for the product, but for
clients
> I have an extended build that builds the core product and the client
> customizations.  In order to do this, I use the core ivy file, AND a
> second client ivy file that has all the dependencies of the client but
> does not depend on the core (since I'm building it at the same time).

>
>  
>
> However, having two ivy files in a single build is problematic
because:
>
> -most of my client dependencies exist in the core product, and I have
to
> be careful to ensure I keep version numbers in sync.
>
> -when I use ivyde, the client project and core project both load their
> dependencies, even if they're the same jar, this is particularly
> problematic if the versions have resolved differently.
>
>  
>
> Anyone have a better idea on how to do this?
>
>  
>
> Also, I'm only using ivy for build time dependency management, I'm not
> using it for deployment or pom/ivy file generation (at least not yet),
> so that does not need to factor into any suggestions.
>
>  
>
>  
>
>  
>
>
>   

Re: Working on multiple dependant projects at once

[Vladimir Ritz Bossicard <vl...@ritz-bossicard.com>]

Mark,

To try to solve this problem, I would distinguish between publishing the 
"product" onto a local vs. central repository.  A local repository is 
similar to a central one, but is just sitting on someone's HD.

For this to work, the ivysettings.xml must first check the local 
repository and then the shared one.

The work flow would then be:

   1. developers check-out the "product" and "client-A" projects locally.
   2. to speed up the developement, "client-A" would depend (in Eclipse) 
from "product"
   3. the developers make modifications to both projects
   4. he publishes the (modified) "product" project onto his local 
repository
   5. when building the "client-A" application, the version from the 
local repository (should) will be downloaded
   6. when everything is fine, the developer checks in the changes for 
the "product" project and ideally triggers a central job (e.g. in 
Hudson) to publish the "product" jars into the central repository.

Could you follow me?

-Vladimir

> I work at a place where we have a "product" and then we have multiple
> "client" customization projects that sit on top (one 'customization' per
> client).
>
>  
>
> The theory is, the "product" is developed by one team, and the
> customizations are done by other teams, and thus in theory the product
> team should have one ivy file, and the client teams would each have
> their own, that simply treats the product as a dependency.
>
>  
>
> In practice, however, client teams are always working on product at the
> same time (in order to fix bugs, add customization points, enhance
> product features etc).
>
>  
>
> So what I've set up a standard ivy/ant for the product, but for clients
> I have an extended build that builds the core product and the client
> customizations.  In order to do this, I use the core ivy file, AND a
> second client ivy file that has all the dependencies of the client but
> does not depend on the core (since I'm building it at the same time).  
>
>  
>
> However, having two ivy files in a single build is problematic because:
>
> -most of my client dependencies exist in the core product, and I have to
> be careful to ensure I keep version numbers in sync.
>
> -when I use ivyde, the client project and core project both load their
> dependencies, even if they're the same jar, this is particularly
> problematic if the versions have resolved differently.
>
>  
>
> Anyone have a better idea on how to do this?
>
>  
>
> Also, I'm only using ivy for build time dependency management, I'm not
> using it for deployment or pom/ivy file generation (at least not yet),
> so that does not need to factor into any suggestions.
>
>  
>
>  
>
>  
>
>
>