ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Zethelius <sv...@expedia.com>
Subject ivy management advise
Date Thu, 12 Apr 2012 17:42:21 GMT
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" />

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message