ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Cache Problems - Need to some answers
Date Tue, 13 Jul 2010 17:55:16 GMT
Scott:
I can offer some perspective on your second item. If you're considering
having two separate caches on the same client just to distinguish between
two different resolvers, that's a bit like wanting to put legs on a car, or
wheels on a horse. Better to ask how to get things working under the
existing paradigm.

I believe one way to accomplish what you want is to have a chain resolver on
your machine that does milestone builds. Within the chain resolver, the
release resolver appears before the milestone resolver. Then—and here’s the
important thing—your resolver(s) should specify checkModified=”true”. See
“Changes in module metadata” under:
http://ant.apache.org/ivy/history/latest-milestone/concept.html#change

This way, if your beta2 version graduates from milestone to release, the
release build will have a newer timestamp than the milestone build in your
cache and Ivy will download it. You may want to experiment with whether you
really need to have the release resolver appear before the milestone
resolver. I’m not sure about a chain resolver’s interaction with
checkModified. This may have something to do with the returnFirst attribute
on chain.

The alternative is to use a versioning scheme that distinguishes between
milestone and release builds. So when you promote a project from the
milestone repo to releases, you change or increment the version in some way.
The argument for this scheme is that, when you get right down to it, the
latest milestone version of your beta 2 release and your actual beta 2
release really are two different things. Hence, they probably should have
different versions.

Using this approach, if you're doing integration builds against your
milestone repository where each latest build is replacing what was there,
then you might give that a version like beta2_milestone. Then when you're
ready to graduate it to release, it becomes just beta2. Your resolver should
know that beta2 is later than beta2_milestone.

Of course, with Ivy, there are umpteen different versioning schemes, so I’m
loathe to say there’s something wrong about milestone and release builds
using the same version.

To me, the crucial question is, “Is my theory correct in that a mismatch in
resolver will not invalidate a cache?” You can see that Ivy does record in
its cache the associated resolver for each module and artifact. However, it
only makes sense to me that Ivy would trust what’s in the cache, regardless
of which resolver it came from.

On Mon, Jul 12, 2010 at 3:21 PM, Scott Goldstein <
Scott.Goldstein@nextlabs.com> wrote:

> I haven't gotten a response, so I'm posting again.  Can anyone provide some
> info on these issues?
>
> Thanks!
>
> Scott
>
> From: Scott Goldstein
> Sent: Monday, June 07, 2010 3:21 PM
> To: 'ivy-user@ant.apache.org'
> Subject: Cache Problems - Need to some answers
>
> I've run into a few caching issues today and I was hoping to get some
> help/answers.  I've debugged into the code and am looking for the following
> info:
>
>
> 1.        The default ivy pattern for a cache is
> "[organisation]/[module](/[branch])/ivy-[revision].xml".  This causes
> problems in my environment, as in my dependency element definitions, I don't
> specify a branch, but in the info element, I do.  And, in at least one of my
> repositories, the branch is not included in the pattern in the resolver.
>  Therefore, whenever it does a cache check, it can't find the ivy.xml in the
> cache, because it's looking in "[organisation]/[module]/ivy-[revision].xml"
> but storing it in "[organisation]/[module]/[branch]/ivy-[revision].xml".
>
> My original solution to this is to define a separate cache for resolvers
> that use the "branch" in their ivy pattern and another for resolvers that
> don't.  However, when I look in the source code at
> DefaultRepositoryCacheManager, it has a pattern for the ivy data file set to
> "[organisation]/[module](/[branch])/ivydata-[revision].properties" and I
> don't see a way to configure this through ivysettings.xml.  I see the
> setDataFilePattern() method, but it doesn't seem to be invoked anywhere.
>
> Questions:  Is my approach the right way to solve this problem?  If so,
> what is this ivy data file?  Will my approach work if the two caches end up
> sharing the same data file (since I can't change the location)
>
>
> 2.       Two of my repositories represent a promotion mechanism.  The first
> is a "milestones" repository that contains betas.  The second is the
> repository that contains releases.  What I'd like to do is promote a build
> from milestone to release and have this be transparent to the client.  I
> haven't tried this yet, to be honest, but based on my debugging of the cache
> today, it looks like if these two repositories/resolvers share the same
> cache, this won't work.  In other words, if a client has a beta 1 in their
> cache, but I promote beta 2 to the releases repository, their cache won't be
> flushed.  Or, more specifically, it looks like the cache won't be
> invalidated if the original resolver (milestones) is not the current
> resolver (releases).
>
> Question:  Is my theory correct in that a mismatch in resolver will not
> invalidate a cache?  If this is true, how do I achieve the use case I'm
> describing?  Do I need to have a separate cache completely for these two
> resolvers?
>
> Thanks for your help!
>
> Scott
>
> - --------------------------------------------------------------------
> STATEMENT OF CONFIDENTIALITY
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain confidential or privileged information. No representation is made on
> its accuracy or completeness of the information contained in this electronic
> message. Certain assumptions may have been made in the preparation of this
> material as at this date, and are subject to change without notice. If you
> are not the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this e-mail and any attachment(s)
> is strictly prohibited. Please reply to the sender at NextLabs Inc and
> destroy all copies of this message and any attachments from your system.
> ======================================================================

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