On 1/31/07, John Williams <[EMAIL PROTECTED]> wrote:
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.
The fallback mechanism in confs use parenthesis. But I'm not opposed to another syntax. 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 say that this can be developed and tested without modifying Ivy, then if the community is ok to adopt it in the Ivy distribution, it would better be part of the official distrib. I really think this behavior should be available out of
the box, even if it's not the default.
I agree. Another advantage I see is that people could use the fallback version constraint even on purpose, I mean outside what would be done by the deliver 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.
I'm not sure to agree, this require more thoughts. I don't like having dynamic version constraints on ivy files in the repository. In this case it's special, since the version constraint is dynamic only in a special case. So I don't know. If we can configure the status for which the fallback version should be used, I think it's more flexible and not too difficult to achieve. BTW, note that as Eric said, the whole problem could be addressed differently with a more flexible cache and local repository management. But I don't know if this means we shouldn't attempt to go in this direction (which has the merit to be pretty simple to implement). - Xavier jw
