Re: object dependency versus versionned object dependency

[Xavier Hanin <xa...@gmail.com>]

On 10/11/07, Olivier RAOULT <ol...@st.com> wrote:
>
>  H All,
>
> If I understood well, dependency concept is based on something like:
>
> *<ivy-module version="1.0">
>     <info organisation="jayasoft" module="hello-ivy" />
>     <dependencies>
>         <dependency org="apache" name="commons-lang" rev="2.0" />
>     </dependencies>
> </ivy-module>*
>
> So, a given version of a father depends *on a given version* of a given
> son.
>
> As it is, and if I want to support commons-lang_2.1, I will have to
> deliver a new hello-ivy_1.1, even if nothing change in the hello-ivy code.
> Yes? No?
>

You can also replace the ivy file for hello-ivy, even though this is not
something I recommend (for build reproducibility concerns), but it's
supported by Ivy as soon as you use checkModified="true".

If the revision number is removed from the constraint, Ivy would consider
> than all commons-lang revisions are allowed (including all future ones).
> Yes? No?
>

You need to put the revision in the constraint.  Use "latest.integration" if
you want to get the latest version available no matter which one it is.

Now, let's assume I would like to be more explicit about what has been
> really tested. For example, let's assume I delivered hello-ivy_1.1, 1.2and
> 1.3, but tested *only* hello-ivy_1.1 with commons-lang_2.0 (the only
> existing at this time), then hello-ivy_1.2 with commons-lang_2.0 and 2.1,
> then hello-ivy_1.3 with commons-lang_3.0. Maybe hello-ivy_1.3 works with
> commons-lang_2.0 as well, but I never tested it. If some end-user requests
> it, I could perform all 1.3/3.0 tests then assert it as a valid (or
> invalid) combination .. without modifying in any manner all these delivered
> objects.
>
> In other words, I would like to manage two type of information: a) a
> stable dependency from a versionned object to a non-versionned one, and b)
> an external and maybe increasing list of valid (or invalid) combinations.
>
> Is there something in Ivy to manage such issue?
>

No, there's nothing to do that, but I've already thought about that. In some
cases, I think we should be able to allow some kind of metadata upgrade: it
can be because we have tested more combinations of dependencies as you said,
or because we have promoted a version from one status to another one. It
would be interesting to have Ivy supports this kind of things.

Another important thing to understand with Ivy is that Ivy do not really
support  a compatibility notion: when you express a dependency on a module,
even if you give a fixed version constraint, you may later end up with
another version of the dependency if another module in your dependency graph
depends on another version. Conflicts managers are used to decide what to do
in such case, the default is to use the latest one. Where this begin to be
cumbersome is when you deliver a module, the default in Ivy is to replace
all dynamic constraints by static one, to ensure build reproducibility. But
this mean that you lose the version constraint (note that this is not
mandatory).
It would be interesting to improve Ivy to store both the original version
constraint (expressing some kind of compatibility) and the exact version
used at deliver time. This would allow more flexible conflict management
whilst preserving build reproducibility.

Xavier

Rgds,
>   Olivier
>
>
>
>


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