On Mon 2008-03-31 at 15:59h, Gilles Scokart wrote on ivy-user:
:
> Well, the use case presented by Niklas is not covered : What if I want
> to exclude a transitive dependency because I'm incompatible with it?
> Maybe I want to tell to my users "hey, never run my code with this
> depdendency!".
>
> Is this scenario realist? I don't know?
One important question (I think) is: If someone has published a module
with a descriptor containing an exclude, what should that tell a
client using that module? It would be very bad if the client had to
make sure that none of its other dependencies doesn't include the
exluded dependency. This would effectively mean that exclude
directives have to be manually propagated up to the root of the
dependency tree (and be added to all published descriptors of modules
along the way). It gets worse when the exclusions evolve over the
revision history of the excluding module. If, on the other hand, the
published module is fine with the excluded dependency being imported
via other modules, then the question is what it really meant by
excluding the dependency.
There are similar questions for <override> and <conflict>.
E.g. if I have a module D depending on modules B and C, which both
transitively depend on a module A, and the descriptor of B specifies
conflict manager X for A, and module B specifies conflict manager Y
for A, and my module D uses the default conflict manager to resolve
conflicts between revisions of A returned by B and C, will B and C be
happy with the result? And this process is complicated by the fact
that descriptors are revision-dependent, i.e. it's not really B and C
that specify conflict managers, it's specific revisions of B and C
that might specify different conflict managers. Ignoring the complex
mess that this already creates ;), the <conflict> directives of some
module B should only be applied after it is known which revision of B
is ultimately selected, to get consistent results. For example, if you
have something like (using proper notation ;)):
#D -> {
#B;1 -> {
#F;1 -> ... -> #A;1
#G;1 -> ... -> #A;2
}
#H -> ... -> #B;2 -> {
#F;2 -> ... -> #A;3
#G;2 -> ... -> #A;4
}
}
and #B;2 specifies a different conflict manager for #A than #B;1,
then if the conflict between #A;1 and #A;2 or between #A;3 and #A;4
is resolved before the conflict between #B;1 and #B;2 is resolved,
then the resulting revision of #A may depend on the order on wich the
direct dependencies of #D (i.e. #B;1 and #H) are traversed. (Note that
(the author/user of) #D might not even be aware of the fact that #H
uses #B.) It is my understanding that Ivy intends to define a
dependency resolution mechanism that is not order-dependent (unlike
the mess you get with Maven ;)).
-- Niklas Matthies
