Gilles,

Representation #1 is used to compute which artifacts must be installed to satisfy some artifact dependencies.

With representation #2, Oleg only solve the problem of determining which version of the available artifacts should be installed (at least, this is my understanding of its encoding).

        Daniel

Gilles Scokart a écrit :
2008/12/20 Daniel Le Berre <lebe...@cril.univ-artois.fr>:
Oleg Gusakov a écrit :
The tree could be walked in two directions, and these approaches are
equivalent, except for b and c optionality:

Representation #1: P2

a1 -> b1 or b2 or b3
a1 -> c1 or c2

b1 + b2 + b3 <= 1  # this one implicates that b is optional
c1 + c2 <= 1       # this one implicates that c is optional


Representation #2: Mercury

b1 -> a1
b2 -> a1
b3 -> a1
c1 -> a1
c2 -> a1
b1 + b2 + b3 = 1
c1 + c2 + c3 = 1


In representation #1, I think you miss a1 = 1.  And I have the feeling
that representation #1 is easier to generalize than Representation #2.
 What happens if I have one level more.  Let say x having a dependency
on a version [1,2].
In representation #1, I keep the same equations :
a1 -> b1 or b2 or b3
a1 -> c1 or c2
b1 + b2 + b3 <= 1
c1 + c2 <= 1

and I add :
x -> a1 or a2  (dependency expressed)
a1 + a2 <= 1

Imagine that a2 has no dependencies, or worse that a2 just has a
dependency on b3.  With the representation #1, I can easily represent
that.
But with representation #2, I don't see what will be your system of
constraints ('b3 -> a1' and 'c1+c2=1'  is not correct anymore).


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




--
             Daniel Le Berre mailto:lebe...@cril.univ-artois.fr
             MCF,    CRIL-CNRS UMR 8188,    Universite d'Artois
             http://www.cril.univ-artois.fr/~leberre

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to