|
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? 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? 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.2 and 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? Rgds, Olivier |
- object dependency versus versionned object dependency Olivier RAOULT
