ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject caching strategies--is there room for a new one?
Date Mon, 31 Aug 2009 03:16:16 GMT
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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message