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
 Shawn.Castrianni@halliburton.com designates 34.254.16.15 as permitted sender)
From: Shawn Castrianni <Shawn.Castrianni@halliburton.com>
To: "'ivy-user@ant.apache.org'" <ivy-user@ant.apache.org>
Date: Thu, 21 Feb 2008 15:44:08 -0600
Subject: RE: transitive dependency override
Thread-Topic: transitive dependency override
Thread-Index: Ach0z6nrgOqY/UL8SwyQ3X0TajOW6AAAt2Dw
Message-ID: 
 <745B9EDF57802349B13F90E4E0B4B86C3B9C3FFE9E@HOUEXCH012.corp.halliburton.com>
References: 
 <745B9EDF57802349B13F90E4E0B4B86C3B9C3FFE9B@HOUEXCH012.corp.halliburton.com>
 <635a05060802211312l7ab737f3t29e0d594d2c5b978@mail.gmail.com>
In-Reply-To: <635a05060802211312l7ab737f3t29e0d594d2c5b978@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I LOVE IT!!!  That adds so much more flexibility to IVY.  I also have alway=
s wanted to know what the original dependency constraints were after publis=
hing, but you can no longer find out after a deliver.

This extra metadata could also come in handy in the report task when the de=
pendency graph is created.  Right now, if you run the report, you can see t=
he dependency constraint rules for the direct dependencies of the module yo=
u are reporting on, but all of the indirect (transitive) dependencies are h=
ardcoded to their specific revision numbers.  Have this extra metadata coul=
d allow the report task to put the original dependency constraint rules on =
all the edges in the graph and the specific revision numbers inside all of =
the nodes.  In my opinion, that is a better report of the dependencies of a=
 module.  It shows the constraint rule used and the actual revision found f=
or all nodes in the graph.

---
Shawn Castrianni
CM Chief Architect
Landmark
Halliburton Drilling, Evaluation and Digital Solutions Building 2
2101 City West Blvd.
Houston, TX  77042
Work:  713-839-3086
Cell:  832-654-0888
Fax:  713-839-2758

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Thursday, February 21, 2008 3:12 PM
To: ivy-user@ant.apache.org
Subject: Re: transitive dependency override

What I dislike with implementing this feature is that it puts more
responsibility to the settings, and from the beginning I've often tried to
avoid putting too much of the resolution logic in the settings, to try to
keep Ivy files self expressive.

But OTOH I understand your use case. Maybe a better solution (but which
would involve more changes in Ivy) would be to keep two versions informatio=
n
per dependency when publishing to the repository : the original version
constraint, and the version that was used when the module was published. I
think this has already been requested before, and I really think it would b=
e
a good improvement to Ivy, because we actually lose some metadata when
calling deliver.

Then we could have a mode during resolve which asks to use original version
constraints instead of delivered ones (maybe per module, to fit your need).
I think this would better fit in Ivy philosophy, but requires more work, an=
d
is different from what you asked before.

WDYT?

Xavier

On Thu, Feb 21, 2008 at 9:40 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> Basically if a new indirect dependency is ready and published in the repo
> and the developer wants to use it now without having to wait for a new
> direct dependency that uses that new indirect dependency to be published,
> this would come in handy.  Or maybe the direct dependency build is broken=
 so
> the developer can't access the new indirect dependency until the build is
> fixed.  There are other scenarios where explicitly specifying a revision =
of
> a module can be useful.  But again, I want that control in the settings f=
ile
> so I don't have to change the ivy.xml files.
>
>
> ---
> Shawn Castrianni
> CM Chief Architect
> Landmark
> Halliburton Drilling, Evaluation and Digital Solutions Building 2
> 2101 City West Blvd.
> Houston, TX  77042
> Work:  713-839-3086
> Cell:  832-654-0888
> Fax:  713-839-2758
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited=
.
>  If you are not the intended recipient (or authorized to receive informat=
ion
> for the intended recipient), please contact the sender by reply e-mail an=
d
> delete all copies of this message.
>


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