Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 209.85.218.175 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=smuH5a0pgA9v3v2mnxYJZwcvrEVzY1XxA8VMl6kVgTKTpPvYTgUK8C43TP5c6yMzBR
         bJPtH060NWGn+83+pLKbXtJPKCLkkX9oqzI0RXHzX25zbstrUNz7Kts/cMqSyBqy5s/9
         +EVs2cyaQqhhcNRhjXbi/5dnWjlbdB3PpD5rI=
MIME-Version: 1.0
In-Reply-To: <1019183757.20090308152429@freemail.hu>
References: <1019183757.20090308152429@freemail.hu>
Date: Sun, 8 Mar 2009 20:06:21 +0100
Message-ID: <e9d8a2610903081206g9b35b23mc69c811270f5190a@mail.gmail.com>
Subject: Re: Chain resolver chaos with local dependency overrides
From: Gilles Scokart <gscokart@gmail.com>
To: ivy-user@ant.apache.org, Daniel Dekany <ddekany@freemail.hu>
Content-Type: multipart/alternative; boundary=001636c5bb71aa2be90464a03629

--001636c5bb71aa2be90464a03629
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I do somthing similar.  When a developper has finish to play with a local
dependency he must clean his local repository, clean his cache and
re-execute a resolve.
Not very nice, but in my context it seems to be OK (we rarely have to play
with local dependencies).


Gilles Scokart


2009/3/8 Daniel Dekany <ddekany@freemail.hu>

> I have a chain-resolver that contains a filesystem-resolver and an
> url-resolver. The filesystem-resolver is local to the developer's
> workstation, while the url-resolver points to a webserver that is
> common for all developers. Normally, Ivy just grabs all dependencies
> from the webserver, but sometimes a developer wants to play locally
> with a bleeding edge version of a *dependency* (which is not yet on
> the webserver), so he publishes that with the filesystem-resolver, so
> only on his workstation Ivy will use that from then. So far so good...
> The problem is with using the version on the webserver again. I tried
> two approaches:
>
> (a)  Ivy should always check both repositories, and chose the version
>    of the module that is the latest. With a chain and the default
>    returnFirst="false" this works as far as the revision "number" of
>    the older and newer stuff differs, but if only the publication
>    date differs (like for two snapshots) Ivy always chooses the
>    revision returned by the earlier resolver of the chain. It does
>    so despite <dependency ... changing="true" />. I checked that Ivy
>    downloads and parses the ivy.xml-s from both Ivy repositories, and
>    that both XML contains correct <info publication="...">, yet Ivy
>    always says that the one downloaded last was the older. That's
>    despite that from the publication attributes it's obvious that it
>    isn't so. Bug?
>
> (b) After (a) failed, I decided that the filesystem-resolver will have
>    priority over the url-resolver (i.e., returnFirst="true"), and I
>    add an Ant task for un-publishing from the filesystem-resolver.
>    (This last is needed for (a) too anyway.) First of all, there is
>    no ivy:unpublish. Luckily I defined and control the
>    filesystem-resolver, so I know what to ant-<delete>, so this part
>    is worked around in this case. The problem is, after deleting from
>    the filesystem-resolver, Ivy still find the module there through
>    the cache. Shouldn't <dependency ... changing="true" />
>    effectively bypass the cache? I checked it, and it kind of did.
>    Ivy tries to open the files in the repository, and it realizes
>    they are not there anymore. But then instead of continuing with
>    the next resolver in the chain, it uses the cached copy of those
>    files that it *knows* to be non-existent. I mean, a cache should
>    reflect what it caches as precisely as it can, as far as it
>    doesn't defeat the performance, and in this case the
>    performance-defeating slow I/O was already done, so why the cache
>    doesn't reflex the new situation? Bug?
>
> And, the point... I guess I try to address a fairly common use-case
> here. What solution you guys use for this? (I try to rely on
> ivy:cachepath instead of ivy:retrieve.)
>
> --
> Best regards,
>  Daniel Dekany
>
>

--001636c5bb71aa2be90464a03629--