ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: transitive dependency override
Date Thu, 21 Feb 2008 21:44:08 GMT
I LOVE IT!!!  That adds so much more flexibility to IVY.  I also have always wanted to know
what the original dependency constraints were after publishing, but you can no longer find
out after a deliver.

This extra metadata could also come in handy in the report task when the dependency graph
is created.  Right now, if you run the report, you can see the dependency constraint rules
for the direct dependencies of the module you are reporting on, but all of the indirect (transitive)
dependencies are hardcoded to their specific revision numbers.  Have this extra metadata could
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 for 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 information
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 be
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, and
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 file
> 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 information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>



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

Mime
View raw message