Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: domain of mgitman@gmail.com designates
 209.85.218.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Kwyn7io2oK+3k5kX17DyVXa750wUOjIs0LYKJiKAj8GFm8tFJa69qlK/DYgS4oAHqP
         VjZjsf1N4BHySASm+FOCSg3k13lvgS0KTcEySX/yYY03TOl3ZctTvCP7gcQmOT34c7ey
         rDh/5lUgKSf2KH83cch6HMZuE6r719myi5Brg=
MIME-Version: 1.0
In-Reply-To: <200909081107.01247.stephen_nesbitt@alumni.cmc.edu>
References: <7916a6a60908302010x5afb2801sf95b2daed68dd747@mail.gmail.com>
	 <7916a6a60908302016r4ebe456r9d366c0308418c9e@mail.gmail.com>
	 <200909081107.01247.stephen_nesbitt@alumni.cmc.edu>
Date: Tue, 8 Sep 2009 16:43:30 -0700
Message-ID: <7916a6a60909081643p4e98a918g3a90cb8dd6631259@mail.gmail.com>
Subject: Re: caching strategies--is there room for a new one?
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=00151747ba9cbd4f6e047319885a

--00151747ba9cbd4f6e047319885a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Steve, thanks for getting back.

I really don't want to go down that rabbit hole of debating
prolific/promiscuous versioning vs. snapshot versioning. Let's assume I've
made the choice to use so-called snapshot versioning, where the CI server
keeps overwriting integration versions when it does an ivy:publish. I can
see three ways to implement that approach which affect caching:
* Have a special integration repository and put checkmodified=3D"true" on t=
he
resolver for that repository. (Forgive me for mistakenly writing
lastmodified in previous posts.)
* Use a naming convention like "-SNAPSHOT" for your integration versions an=
d
on the resolver specify a combination of checkmodified=3D"true" and a
changingPattern.
* Override caching on a per-module basis using changing=3D"true".

While I would say that the support for changing=3D"true" could be made easi=
er,
even then I wouldn't want to go with it. Just too high-maintenance. Same fo=
r
a naming convention like "-SNAPSHOT". That leaves only the first approach:
integration repository + checkmodified=3D"true".

While I think having an integration repository is a good idea in its own
right, I hate for it to be the only way to do snapshot versioning that
doesn't have hidden landmines. One of the things I like about Ivy is that i=
t
offers you different ways to accomplish something. One thing I don't like i=
s
that--fortunately, only on rare occasion--when you get right down to it,
there's really only one way that works and isn't a pain in the butt, and al=
l
the other approaches, while available, are really deprecated.

Now you could try to make the hard options--changing=3D"true" and
changingPattern--a little easier. But they'll still be hard options. What
I'd like is just to have another easy option in the mix. My proposal is put
another filter on checkmodified=3D"true"--where it only checks for a given
status or lower. This way you don't have to set up a special integration
repository from the outset just to avoid running into insidious, mysterious
bugs that eventually trace their way back to over-caching.

On Tue, Sep 8, 2009 at 11:07 AM, Stephen Nesbitt <
stephen_nesbitt@alumni.cmc.edu> wrote:

> Mitch:
>
> 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 artifac=
ts
> with -SNAPSHOT or something and avoidance of promiscuous versioning. If s=
o,
> what I would really like to know is what is the issue with promiscuous
> versioning and what problem does tagging everything with -SNAPSHOT provid=
e?
>
> I have a sneaking suspicion that the "changing" attribute is really a hac=
k
> to
> cover a problem in repository management.
>
> -steve
>
> Stephen Nesbitt
> Absaroka Tech
> Build and Configuration Management Consulting
> steve.nesbitt@absaroka-tech.com
>
> 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=3D"true"
> >  by itself. This makes sense if you can split your repositories into
> >  integration and release repositories. Trust cache for release; distrus=
t
> >  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 ha=
ve
> 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=E2=80=93SNAPSHOT
> >    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 =E2=80=93SNAPSHOT, but you can deal =
with the
> >    overhead of (A) remembering to manually specify changing=3D"true" an=
d
> 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 separat=
e
> > integration repository has value in its own right apart from caching.)
> > Consider these observations:
> >
> >    - Under normal caching situations, there's a high correlation betwee=
n
> >  (A) your willingness to trust the cache for a given module and (B) tha=
t
> >  module's publication status. Milestone or release=3Dtrust cache.
> >  Integration=3Ddistrust cache.
> >    - There's a certain information redundancy in having an integration
> >    repository. All the modules published there have status=3D"integrati=
on",
> >    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 go=
es
> >    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=3D"true" maxcheckstatus=3D"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=3D"true", you have to admit this is worlds simpler.
> >
> > Or is it? So what am I missing here?
> >
>

--00151747ba9cbd4f6e047319885a--