From ivy-user-return-3379-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org Mon Jun 16 14:30:32 2008 Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 83399 invoked from network); 16 Jun 2008 14:30:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Jun 2008 14:30:32 -0000 Received: (qmail 23513 invoked by uid 500); 16 Jun 2008 14:30:34 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 23492 invoked by uid 500); 16 Jun 2008 14:30:34 -0000 Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@ant.apache.org Delivered-To: mailing list ivy-user@ant.apache.org Received: (qmail 23481 invoked by uid 99); 16 Jun 2008 14:30:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2008 07:30:33 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of davidcorley@gmail.com designates 209.85.198.240 as permitted sender) Received: from [209.85.198.240] (HELO rv-out-0708.google.com) (209.85.198.240) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2008 14:29:44 +0000 Received: by rv-out-0708.google.com with SMTP id b17so4597434rvf.40 for ; Mon, 16 Jun 2008 07:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=0XIG1GCFA0isrgrUFRdmarVHERqPmT1G/CPzb7M+J7o=; b=m35Z+W6a3c4flzvfMcJySj7opyTxNPmpru8c2oUfsy/laiYx/+HmW+7jcyVHzXrhWT elhzgCM/mmxS6o9+6fVyL00ePP9BFVNsBYcQ7daOKr59ric+TY+iFqI7w0lsXnXonsGr FEvN+q/UQ2m2VDei1rUk77kkAjqig0sAVTM5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=RTognADkx5Rivs7HThJY7ffiaXqN2NlRRSHpUWvvetSNqmgW28G0xDbOJ03zzSsRMi todgz757fmTPO58i9Uepy9L5MJtnR4+84JkObQCEqql7eAJdXJ4DJwzDweePkUMgNd51 naiuVXTF3U9L+HqxinYYJLBAJW2P3c6V4H9wE= Received: by 10.141.79.12 with SMTP id g12mr3705856rvl.182.1213626602672; Mon, 16 Jun 2008 07:30:02 -0700 (PDT) Received: by 10.140.255.16 with HTTP; Mon, 16 Jun 2008 07:30:02 -0700 (PDT) Message-ID: <26c776bf0806160730r52975af8i1f256bbe38a13b45@mail.gmail.com> Date: Mon, 16 Jun 2008 15:30:02 +0100 From: Dave To: ivy-user@ant.apache.org Subject: Re: Ivy:retrieve not picking up new jars In-Reply-To: <7c6512110806160701v1d890639kc03fb3a61ea04411@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18176_222779.1213626602638" References: <26c776bf0806160548g5d928c3eoe97f5a8b2b00a945@mail.gmail.com> <7c6512110806160636v2801e4c4nb6a95d0add7da54e@mail.gmail.com> <26c776bf0806160644m5a37bf31p8187445f86b88fe8@mail.gmail.com> <7c6512110806160701v1d890639kc03fb3a61ea04411@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_18176_222779.1213626602638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'll work around the issue using one of your suggested methods. I can't understand why I'm able to recursively resolve everything when nothing is in the cache, but once a revision is in the cache, a dependency on a newer revision cannot be resolved. It's counter-intuitive (as you say) and unexpected behaviour surely? i.e., the first time I resolved Module A, it got everything I needed down through the dependency tree. However, once that first resolve is carried out, there's no way to allow for the fact that a dependency of a dependency will change revision? Surely that's an Ivy bug? On Mon, Jun 16, 2008 at 3:01 PM, Colin Fleming wrote: > Unfortunately, yes - as far as I know there's no way to recursively > resolve all dependent modules. This is something I've always found > pretty confusing - sometimes it seems counterintuitive. Check out the > buildlist task - it will run an action for a list of modules in > dependency order, and thus you're guaranteed to always have your > dependencies resolved. > > Cheers, > Colin > > 2008/6/16 Dave : > > I resolved Module A with the refresh attribute set to true. > > I though this would transitively resolve Module B? Am I wrong? > > > > On Mon, Jun 16, 2008 at 2:36 PM, Colin Fleming < > colin.mailinglist@gmail.com> > > wrote: > > > >> Hey Dave, > >> > >> Have you resolved module B after updating its dependencies? Resolution > >> will place the resolved ivy file with the updated dependencies in the > >> cache, and then module A should pick it up. > >> > >> Cheers, > >> Colin > >> > >> 2008/6/16 Dave : > >> > Hey all, > >> > I've got 3 modules which are interdependent > >> > Module A depends on Module B which in turn depends on Module C > revision > >> N. > >> > > >> > I updated Module B's ivy.xml to depend on a newer version of Module C, > >> but > >> > the command keeps using revision N instead of N+1. > >> > How can I tell Ivy to re-resolve the dependency revisions every time I > >> call > >> > a retrieve? > >> > > >> > If you need any more info, let me know. > >> > > >> > > >> > Regards, > >> > Dave > >> > > >> > -- > >> > There are 10 types of people in the world. > >> > Those who understand binary and those who do not. > >> > > >> > > > > > > > > -- > > There are 10 types of people in the world. > > Those who understand binary and those who do not. > > > -- There are 10 types of people in the world. Those who understand binary and those who do not. ------=_Part_18176_222779.1213626602638--