On 1/31/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
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?
Keeping a single 'rev' attribute does seem like a better choice,
though for the syntax I'd rather see a comma-separated list to match
how configs are done.
When you say "without even modifying Ivy", are you suggesting that
users of Ivy should implement the functionality themselves, or just
saying how you'd want the feature to be implemented in the Ivy
distribution? I really think this behavior should be available out of
the box, even if it's not the default.
I agree with your suggestion of assuming integration versions can be
deleted but not other versions, but I think including both the exact
revision number and the revision pattern is always the right thing to
do when publishing, since the resolver can always ignore anything but
the exact revision.
jw
