ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Nesbitt <>
Subject Re: caching strategies--is there room for a new one?
Date Tue, 08 Sep 2009 18:07:01 GMT

I guess I'm not completely clear on what problem you are trying to solve here. 
Is it to make using the "changing" attribute easier?

From a configuration management perspective, I consider any need for a 
"changing" flag to be poor (or at least not ideal) practice - it's essentially 
an admission that I don't know what I've got and that I have failed to 
uniquely identify my artifacts.

I suspect this has something to do with the convention of tagging artifacts 
with -SNAPSHOT or something and avoidance of promiscuous versioning. If so, 
what I would really like to know is what is the issue with promiscuous 
versioning and what problem does tagging everything with -SNAPSHOT provide?

I have a sneaking suspicion that the "changing" attribute is really a hack to 
cover a problem in repository management.


Stephen Nesbitt
Absaroka Tech
Build and Configuration Management Consulting

On Sunday 30 August 2009 08:16:16 pm Mitch Gitman wrote:
> Carlton's question came at a time when I was pondering the caching
> strategies Ivy implicitly offers. I can identify four:
>    1. Always trust the cache.
>    2. For a given resolver, never trust the cache, i.e. lastmodified="true"
>  by itself. This makes sense if you can split your repositories into
>  integration and release repositories. Trust cache for release; distrust
>  cache for integration.
>    3. For a given resolver, only distrust the cache when the revision value
>    meets a specified changing pattern. This makes sense if you don't have a
>    separate integration repository but you don't mind going to the trouble
>  of giving all your integration revisions the same naming pattern, like
>    suffix.
>    4. Check the repository on a per-dependency basis. This only makes sense
>    if you don't want to use a separate integration repository or a special
>    revision naming convention like –SNAPSHOT, but you can deal with the
>    overhead of (A) remembering to manually specify changing="true" and then
>    (B) remembering to turn it off when you're ready to do a release
>  publish.
> Approach 4 is really high-precision, but it's just so high-maintenance and
> error-prone. I wish there were a way with *ivy:deliver *or *ivy:publish *to
> automatically turn off the changing mode, such as if you're publishing to
> release status. I mean, it doesn't make sense for an Ivy module in release
> status to be depending on other Ivy modules that could be changing out from
> under it.
> Anyway, I can understand why approach 2, in combination with an integration
> repository, is recommended.
> But I wonder if there's potentially a simpler approach where you don't even
> need a separate integration repository. (I acknowledge having a separate
> integration repository has value in its own right apart from caching.)
> Consider these observations:
>    - Under normal caching situations, there's a high correlation between
>  (A) your willingness to trust the cache for a given module and (B) that
>  module's publication status. Milestone or release=trust cache.
>  Integration=distrust cache.
>    - There's a certain information redundancy in having an integration
>    repository. All the modules published there have status="integration",
>    but just the existence of the repository is saying the same.
>    - Under normal circumstances, a module graduates from integration to
>    milestone to release (using the default statuses). A module never goes
>    backwards in status. That makes about as much sense as flunking from
>  sixth grade down to fifth grade.
> So what if you could specify something like the following on a resolver?
> checkmodified="true" maxcheckstatus="integration"
> What would this combination mean? For any given cached module, Ivy will go
> out to the Ivy repository and compare the last modified timestamp only if
> the cached ivy.xml has a status of integration or lower. Once Ivy downloads
> a copy of that module that has a higher status, it subsequently stops
> checking. But that's what you want.
> I can understand why folks wouldn't have use for such a feature if they're
> already using an integration repository. But if Ivy's already
> supporting changingPattern
> and changing="true", you have to admit this is worlds simpler.
> Or is it? So what am I missing here?

View raw message