On 1/31/07, John Williams <[EMAIL PROTECTED]> wrote:
I've found a somewhat common situation that Ivy deals with very
poorly. I have a fix in mind, but it involves extending the ivy.xml
syntax.
The problem occurs when a required revision of a module is deleted,
such as when a developer decides to get rid of his/her local version
of a module and go back to using a shared version. The problem arises
because I've decided (through painful experience) that local
publications should use different revision numbers from shared
publications.
Suppose there are 3 modules, A, B, and C, and each has a 1.0-local
version in the local repository and a 1.0 version in the shared
repository. Also, C depends on B with rev=1+, and B depends on A with
rev=1+. Now, suppose I decide I'm done working on module A, so I
delete the local revision. Now when I try to resolve module C, it
fails because the published ivy.xml of B depends on rev 1.0-local of
A, which no longer exists.
Ideally, I'd like Ivy to use rev 1.0 of A, which would be allowed by
the ivy.xml file for B, but the *published* ivy.xml for B has the
revision of A changed from 1+ to 1.0-local, so Ivy has no way of
knowing that 1.0 is an acceptable revision. The change I want to make
in the ivy.xml files is that each dependency in a published ivy.xml
should have *two* revisions--one containing the actual revision in use
at the time of publication, and one copied verbatim from the
hand-written ivy.xml. During resolution, the actual revision would
always be preferred, and the original pattern would be used as a
backup when the original revision is not available.
The problem is quite common, and the idea is interesting... However
I'm not sure to share your vision about the solution. What I don't
like is to split the version constraint in two separate attributes.
What you want is a mechanism to express a version constraint like
"take 1.0-local, and if it doesn't exist, take 1+". For me this is
only one version constraint, and I'd prefer expressing it as one
expression in the rev attribute. If you think about it, this is very
similar to the fallback mechanism used for configurations. If we
follow the same notation it would be rev="1.0-local(1+)".
One advantage I see to this solution is that it may be done without
even modifying Ivy: create your own VersionMatcher, recognising this
syntax, and you're done for the resolve part. And to put use this
notation during deliver, using a custom
PublishingDependencyRevisionResolver should be ok.
Now I don't think this should be the default behaviour, even if it
could be useful for others. Maybe something using the status to do
that only if the dependency may be deleted (if we say for example that
an integration version may be deleted, but not a milestone or a
release).
What do you think?
Xavier
--jw
