On 1/31/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
I think this would another issue that could be resolved by the decorators for caching. Some of the posts I've made before about doing local overrides go into more depth on approaches to that w/o changing local revision numbers and the cache control would address the gotchas.
Yes, the use of decorators for caching would address this issue in a much cleaner way, even if I'm still not sure to see the complete picture. But the more I think about it, the more I think it would really be nice to have this new cache management in the next version. What do you think?
- Xavier
On 1/31/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > 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 > > > -- - Eric
