I'm not sure that dependencies on intersections of configurations are
welldefined with regard to transitive dependencies. Suppose that A
depends on the intersection of B and C, and B depends on D, and C on
E. Now does that mean that A transitively depends on the union of D
and E, or on their intersection? Or is the intersection of the
_dependencies_ of B and C taken, which would mean neither of D and E?
If you say "intersection", then you probably get too few artifacts. If
you say "union", then it begs the question whether the intersection
was really an intersection. Also, with "union", if you decide to turn
B and C into "virtual" modules and move their to B' and C', with B>B'
and C>C', then suddenly someone depending on the intersection of B
and C will get the union of the artifacts from B' and C' instead of
their intersection.
It seems to me that for welldefined and robust intersection semantics,
Ivy would need to know the actual dependencies on the artifact level,
so that it can accurately determine the dependencies of arbitrary
artifact (sub)sets.
 Niklas Matthies
On Wed 20090415 at 10:49h, Shawn Castrianni wrote on ivyuser:
> I see. I assumed the wildcard usage was only applicable to the
> dependency tags where you are trying to use configurations. You are
> saying that configuration declarations themselves can also use the
> wildcards. This should work, however, I still prefer my design. It
> just feels more elegant and powerful by allowing full Boolean
> operations with configurations (union, intersection, difference,
> etc). But yes, your approach would be less of an impact to others.
>
> 
> Shawn Castrianni
>
> Original Message
> From: Niklas Matthies [mailto:ml_ivyuser@nmhq.net]
> Sent: Wednesday, April 15, 2009 5:23 AM
> To: ivyuser@ant.apache.org
> Subject: Re: configuration help
>
> On Wed 20090415 at 04:48h, Shawn Castrianni wrote on ivyuser:
> > I suppose that would work, but I think allowing "configuration
> > intersection" where a module declares a dependence on the
> > intersection of 2 or more configurations of another module is a
> > cleaner approach. Your wildcard approach would require lots of
> > configurations for all permutations of all axis to be declared which
> > might clutter up the ivy.xml file.
>
> Ok, I skimped over the details. The intent of my approach was exactly
> that you wouldn't have to declare all combinations, and instead can
> use wildcards when declaring configurations and artifacts. This means
> that the set of concrete configurations is potentially openended,
> yes, because anything matching the wildcards is admissible. The point
> of this approach is that it retains the property that dependencies are
> still defined just in terms of singular configurations, not
> intersections of configurations or whatnot. This likely makes it
> easier to implement, would affect less other code and hence be more
> robust.
>
>  Niklas Matthies
