ivy management advise

[Sven Zethelius <sv...@expedia.com>]

We have multiple repositories representing the status of the modules within (e.g. a release repository, releasecandidate, continuousintegration, etc).  Multiple teams within the company publish to these repositories so the modules can be shared.  We've structured the chain resolver with the most stable repository first, decending in order of stability, and using to returnFirst="true" to pick up the most stable build.  This allows us to say rev="[1.0,2.0[" and pick up the release version 1.1, but not try to get the 1.2.1.0 continuousintegration that another team hasn't yet said was stable.  Alternatively the team that needs the 1.2.1.0 can rev="[1.2,2.0[" to pick up the continuousintegration build.

The tension in this setup is that often times a team wants the continuousintegration of modules they are working on, and having to update the ivy file each time to do a build can be burdensome.  Often times, teams switch the returnFirst flag, but that has the downside of risking finding continuousintegration from other teams.

Does anyone have advice?

I was thinking maybe needing a custom Resolver that would allow the declaration of the Resolver at the dependency (e.g. the most stable chain or the most relevant).  This would allow a module to declare the dependencies it only wants to see stable revisions for,  while other dependencies to use the unstable revisions.  Thoughts?

<dependency name="foo" resolver="stable" />
<dependency name="bar" resolver="unstable" />

Re: ivy management advise

[Tom McGlynn <tm...@ieee.org>]

Consider using the branch attribute of dependency:

<dependency name="foo" branch="release" />
<dependency name="bar" branch="continuousintegration" />

Use [branch] in your resolver patterns.


On Thu, Apr 12, 2012 at 1:42 PM, Sven Zethelius <sv...@expedia.com> wrote:

> We have multiple repositories representing the status of the modules
> within (e.g. a release repository, releasecandidate, continuousintegration,
> etc).  Multiple teams within the company publish to these repositories so
> the modules can be shared.  We've structured the chain resolver with the
> most stable repository first, decending in order of stability, and using to
> returnFirst="true" to pick up the most stable build.  This allows us to say
> rev="[1.0,2.0[" and pick up the release version 1.1, but not try to get the
> 1.2.1.0 continuousintegration that another team hasn't yet said was stable.
>  Alternatively the team that needs the 1.2.1.0 can rev="[1.2,2.0[" to pick
> up the continuousintegration build.
>
> The tension in this setup is that often times a team wants the
> continuousintegration of modules they are working on, and having to update
> the ivy file each time to do a build can be burdensome.  Often times, teams
> switch the returnFirst flag, but that has the downside of risking finding
> continuousintegration from other teams.
>
> Does anyone have advice?
>
> I was thinking maybe needing a custom Resolver that would allow the
> declaration of the Resolver at the dependency (e.g. the most stable chain
> or the most relevant).  This would allow a module to declare the
> dependencies it only wants to see stable revisions for,  while other
> dependencies to use the unstable revisions.  Thoughts?
>
> <dependency name="foo" resolver="stable" />
> <dependency name="bar" resolver="unstable" />
>