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 xavier.hanin@gmail.com
 designates 209.85.162.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Iv/h/iTBiZC4BKSLc6aKg6i4LDNg2IqwpTp1jesjuvXlAwMmRVmRsVh9kL6K6xZmWOUg4AGxKAiR5p92t5BIk7V84iCH2LXojdbcXq+a9OL9QVz0x7SYzI03ET3VS4oABhAVS3aZBM9PWnUiICaEA96jYUJ/kWC0rmt5kmWa9hQ=
Message-ID: <635a05060803241130i40c7ed0ardee5af12b4534a1f@mail.gmail.com>
Date: Mon, 24 Mar 2008 19:30:49 +0100
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
In-Reply-To: <20080227203028.0d4f5598@sbs173>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5447_13230764.1206383449568"
References: <20080226184625.7decc0cd@sbs173>
	 <635a05060802270127u45d34548kb398ec4c259dc136@mail.gmail.com>
	 <20080227115305.1a40c042@sbs173>
	 <635a05060802270523i1512e901xc866a238388be697@mail.gmail.com>
	 <20080227203028.0d4f5598@sbs173>

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

I've started working on this, and come close to a solution. To finalize my
work, we need to decide upon the syntax we want to use in Ivy files to
support transitive dependency override mechanism.

After some more thoughts on the feature and how it relates to existing Ivy
features, I think we now have 3 different ways to influence transitive
dependencies in an Ivy file:
- transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
This feature relies on an 'exclude' tag directly under the 'dependencies'
element.
- setting specific conflict managers for transitive dependencies. This
relies on a 'conflicts' element and its child elements 'manager'.
- overriding version and/or branch of transitive dependencies. In the
implementation, I've opened the door to more feature than that, by
implementing a dependency descriptor mediator mechanism. Whenever we load a
module descriptor dependency descriptors to resolve them, we first ask all
the dependers to mediate each dependency descriptor. Then we use the
mediated dependency descriptor to resolve the dependency, instead of the
original one. For the moment I've only implemented one mediator, called
override. But we could later imagine other kinds of mediation which happens
before actual dependency resolution. For the moment I've used this syntax
for this new feature:
    <engine-hints>
        <mediation>
            <override org="yourorg" module=".*1" matcher="regexp"
branch="BRANCH" rev="1.0" />
        </mediation>
    </engine-hints>
This section is put directly under ivy-module element. What I would like to
do is group the three kind of transitive dependencies hints we can give to
the resolve engine in an ivy file. I'm still wondering what is the best
syntax, and if we can afford deprecating the syntax of conflicts and module
wide exclude. If we agree to deprecate them, here's one idea for the new
syntax:
<ivy-module>
  <dependencies>
    <dependency ... />
    <dependency ... />
    ...
    <hints>
      <exclude org="" module="" matcher="" ... />
      <conflict org="" module="" matcher="" rev|manager="" />
      <override org="" module="" matcher="" branch="" rev="" />
    </hints>
  </dependencies>
</ivy-module>
The conflict tag is similar to the current conflicts/manager tag, except
that the 'name' attribute is replaced by 'manager'.
All three kind of hints share the same attribute triple (org - module -
matcher). The usage of this uple is slightly different in exclude, where it
also applied to other attributes, such as artifact (to name the artifacts to
exclude transitively).

Another approach would be to put the hints section directly under ivy-module
instead of under dependencies (as it's the case for conflicts/manager
today). I think I prefer the former approach I propose.

This is open to discussion, please give your feedback, once 2.0 will be out
we won't be able to go back.

Xavier

On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <harry@unheit.net> wrote:

> On Wed, 27 Feb 2008 14:23:50 +0100
> "Xavier Hanin" <xavier.hanin@gmail.com> wrote:
>
> > Could you open an issue about that?
>
> Here it is: https://issues.apache.org/jira/browse/IVY-753
>
> harry
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

------=_Part_5447_13230764.1206383449568--