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 a–SNAPSHOT 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?
