ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Mon, 31 Mar 2008 16:20:19 GMT
On Mon, Mar 31, 2008 at 5:05 PM, Niklas Matthies <ml_ivy-user@nmhq.net>
wrote:

> 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 ;)).

You raise some very interesting issues, along with a good understanding of
the complexity behind implementing this kind of feature. IMO, letting a
module give rules for the caller is really a complex feature which requires
a lot of design and testing. I don't think we are ready to go into this kind
of feature yet, so I'd keep the exclude/override/conflict feature as
implemented ATM. OTOH, feel free to open an issue in JIRA detailing what
you'd like to have (letting a module exclude another one in whole dependency
graph).

Xavier

>
>
> -- Niklas Matthies
>



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message