Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of llignhoj@gmail.com designates
 209.85.198.186 as permitted sender)
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=D343EBDFcQW+uC0Liltsdz6QUrCWfzxuQMyKMOXobtTHSxLBiEM65V4uKM0tYjS77tvdJO0UO6HwLJFafZoshjAY5d6H7OOdA+Tt5rWhd4YSLtdcaJ/RAir/lhFH27dgtlKgDW5fsngPrNF3xNqicQ3MKYAHYf/JB5J8XB6UmU8=
Message-ID: <49c77ae40712101608h78a91d19w1894027568a6142f@mail.gmail.com>
Date: Tue, 11 Dec 2007 09:08:28 +0900
From: "John Gill" <llignhoj@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Sharing ivyconf.xml
In-Reply-To: <15412A37E8C9574393B24ADD991FAA7608C3F75379@MERCMBX14.na.sas.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_17832_14080430.1197331708516"
References: <20071205135552.GA91121@nmhq.net>
	 <345520A34347BA49B798F70B218ACD13043697F5E3@MERCMBX14.na.sas.com>
	 <20071210111807.GB47609@nmhq.net>
	 <49c77ae40712100447s7b793aefs69e1ab633d937fe6@mail.gmail.com>
	 <20071210134825.GG47609@nmhq.net>
	 <20071210104139.iucaq3x18g8osook@intranet.digizenstudio.com>
	 <15412A37E8C9574393B24ADD991FAA7608C3F75379@MERCMBX14.na.sas.com>

------=_Part_17832_14080430.1197331708516
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think your on the right track here. Resolving for installation and
deployment is a separate exercise.

On Dec 11, 2007 1:00 AM, Nascif Abousalh-Neto <Nascif.AbousalhNeto@sas.com>
wrote:

> Not always. If you publish a module with an unresolved configuration, and
> you have dynamic dependencies on that configuration, they will be left
> unresolved (i.e. "rev='latest.integration'") in the repository.
>
> And why would you ever publish without resolving? We just found an use
> case: circular dependencies combined with dynamic revisions. We use both
> "compile" and "runtime" configurations, and we found out that some modules
> introduced circular dependencies using the second one. If we resolved both,
> we would end up with the wrong resolved versions, by virtue of dynamic
> versions and build ordering - since you can't build the entire cycle in the
> same pass, the first one would get an incorrect (old) version.
>
> So we are going to resolve only for compile, then build and publish. Only
> in a second pass we will resolve for runtime (when we actually need it, for
> example to create installers or testware to test the software).
>
> Now let me get my pain medicine... :-)
> /Nascif
>
> -----Original Message-----
> From: Jing Xue [mailto:jingxue@digizenstudio.com]
> Sent: Monday, December 10, 2007 10:42 AM
> To: ivy-user@incubator.apache.org
> Subject: Re: Sharing ivyconf.xml
>
>
>
> Quoting Niklas Matthies <ml_ivy-user@nmhq.net>:
>
> > I agree (in theory ;)). But that's not really my point. My point is
> > that you can't (practically, reliably) have Ivy dependencies from
> > module revisions onto shared Ivy settings.
> > Because the purpose, or
> > at least one major purpose, of the Ivy settings is to define the
> > resolution process across available revisions (in particular in the
> > light of dynamic dependencies and non-strict conflict resolution).
>
> If I understand it correctly, isn't this resolution process only
> involved when the module is having its dependencies resolved for the
> first time, prior to publish?  Once it's published, the dependencies
> are fixed in the published version of ivy.xml, which is anchored by a
> versioned repository. So when this module A participates in the
> resolution process of another module B, the original ivy settings
> under which A was resolved shouldn't matter at all.
>
> ...right?  (argh this thing makes my head hurt. :-) )
>
> Cheers.
> --
> Jing Xue
>
>
>


-- 
Regards,
John Gill

------=_Part_17832_14080430.1197331708516--