ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <>
Subject Re: feature request: configuration intersections only implemented halfway
Date Wed, 29 Jul 2009 22:04:00 GMT
Shawn, I apologize for putting the idea out there that configuration
intersections should be removed entirely from Ivy. Truth be told, I'd be
having just as big a conniption as you would if that really were to happen. The
reason I broached that thought was merely to acknowledge that there may be
some philosophical opposition to the entire concept.

I think Mitch has pretty accurately described the real-life business problem
I'm facing now. I don't want to specify an artifact that by itself is
<artifact ... conf="windows,debug" />
And then see a consumer Ivy module ask for "windows,debug". If that happens,
my system blows up. The way things are now, there's no way to prevent that
from happening and there's no EASY way to communicate when a union is really
a union and when it's not. I tried to convey the problem I'm facing with the
"rock" and "hard place" passage of my original post.

It seems like the way configuration intersections are implemented now is a
bit like the sort of sausage-making compromise that happens with
legislation. Some people don't want something at all, other people want
something in its full form, and in the process of meeting halfway, neither
party is left entirely happy.

So what I would propose is a two-step process: a quick fix followed by a
long-term solution.

The quick fix I'd like to see for Ivy 2.1 is to allow intersections to be
specified on publication artifacts. The long-term solution, which I think
would appease the people (including me) who have certain philosophical
concerns about intersections, is to transition to a module descriptor API
whereby, in addition to the existing simple Ivy confs, you also can have
conf-like elements out of which composite intersection Ivy confs can be

I really appreciate your feedback on my posts.


On Wed, Jul 29, 2009 at 11:39 AM, Shawn Castrianni <> wrote:

> First, I will admit I did not ready every word of your post as it was
> lengthy.  Therefore, I will only comment on what caught my eye.
> 1. " However, according to system's ivy.xml, this windows+debug syntax is
> useless and meaningless. The implicit request for
> art1d.dll could just as well be expressed as: <dependency ...
> conf="default->windows,debug" />"
> This is not true.  "default->windows,debug" means give me all of the
> artifacts that exist in either (union) configurations windows and debug.
>  Whereas, "default->windows+debug" means give me all of the artifacts that
> exist only in both (intersection) configurations windows and debug.  If I am
> trying to build a windows debug version of my module, than I don't want all
> the windows artifacts and all the debug artifacts.  All the windows
> artifacts will give me release artifacts too.  All the debug artifacts will
> give me other platforms artifacts too.  Since I am building my module in
> debug mode, release artifacts do me no good.  Since I am building on
> windows, linux artifacts do me no good.  Therefore, the only way for me to
> get exactly what I want is the intersection notataion of windows+debug.
> 2. "So again, let's either implement configuration intersections fully or
> remove configuration intersections entirely from Ivy."
> I requested this feature.  I have a real world use case for it as described
> above.  It solves my problem beautifully.  Its existence in ivy does not
> hurt anybody if they don't use it.  Removing it only hurts me and doesn't
> help anybody else.
> ---
> Shawn Castrianni
> -----Original Message-----
> From: Garima Bathla []
> Sent: Wednesday, July 29, 2009 1:11 PM
> To:
> Subject: feature request: configuration intersections only implemented
> halfway
> I've come to the conclusion that the new configuration intersections
> feature
> is implemented only halfway, and as a result it presents an inconsistent,
> misleading, confusing contract. Either we yank it out from Ivy entirely or
> we implement it fully.
> Suppose I have an Ivy module called system with configurations like so:
> <configurations>
>  <conf name="windows" grouping="platform" />
>  <conf name="linux" grouping="platform" />
>  <conf name="release" grouping="quality" />
>  <conf name="debug" grouping="quality" />
> </configurations>
> Plus publication artifacts like so:
> <publications>
>  <artifact name="art1" type="dll" conf="windows,release" />
>  <artifact name="art1d" type="dll" conf="windows,debug" />
>  <artifact name="art1" type="so" conf="linux,release" />
>  <artifact name="art1d" type="so" conf="linux,debug" />
> </publications>
> Suppose I have an Ivy module called consumer with a dependency on system
> like so:
> <dependency ... conf="default->windows+debug" />
> Now, this + notation is allowed by Ivy, thanks to the configuration
> intersections feature. However, according to system's ivy.xml, this
> windows+debug syntax is useless and meaningless. The implicit request for
> art1d.dll could just as well be expressed as:
> <dependency ... conf="default->windows,debug" />
> Why? Because art1d.dll is being published in the union, so if you want
> art1d.dll, then you should just ask for the union. (Never mind that, if you
> only consider only the configurations and not the publications to be the
> Ivy
> module's interface, then the fact that art1d.dll is being delivered via the
> union should be encapsulated from the consumer.) Anyway, if you ask simply
> for the union, you'd also get art1.dll and, which you don't want.
> So now you're having to delve into what the particulars of the publication
> artifacts (again, violating idea of configurations being the interface and
> encapsulating publications) to try to divine something that is not
> explicitly there.
> Worse, what if the creator of the system Ivy module really did want the
> unions to work as unions? Asking for intersections is an attempt to
> undercut
> the interface offered by the dependency module. There's nothing about the
> following interface (to the extent that publication artifacts can be
> considered an interface) to suggest that intersections are involved-unless
> you're really, really clever at reading between the lines:
> <artifact name="art1" type="dll" conf="windows,release" />
> <artifact name="art1d" type="dll" conf="windows,debug" />
> <artifact name="art1" type="so" conf="linux,release" />
> <artifact name="art1d" type="so" conf="linux,debug" />
> What if you were really, really clever though? You could divine that, "Hey,
> look at all those combination patterns. You could make intersections out of
> them." Wow, though, that's complicated.
> Here's what bothers me about this contract as a senior enterprise
> developer.
> We put a premium on programming languages' ability to express constructs in
> as simple, expressive, and intuitive a manner as possible. But when you get
> right down to it, Ivy too is a language. Or to be precise, Ivy provides a
> general-purpose language for transitive dependency management/artifact
> retrieval. In that context, Ivy should strive to express dependencies in as
> simple, intuitive, and expressive a manner as possible. It's our instinct
> as
> developers to make sure we're no less smart than the next guy, to try to
> understand anything, no matter how complex, that gets thrown at us. But in
> the course of trying to understand complexity, we tend to lose sight of
> when
> complexity becomes needless. In today's world, we don't use Roman numerals
> so that we can bask in our cleverness, we use decimals so we can get the
> job
> done. The implicit intersection contract above is too complicated.
> So again, let's either implement configuration intersections fully or
> remove
> configuration intersections entirely from Ivy. What we have now is a
> confusing, complicated compromise that suggests that we couldn't make up
> our
> minds about this feature.
> You can tell where I stand on that either/or. I want configuration
> intersections implemented fully, and that means simply that the + notation
> should be allowed on artifact confs, like so:
> <artifact name="art1" type="dll" conf="windows+release" />
> <artifact name="art1d" type="dll" conf="windows+debug" />
> <artifact name="art1" type="so" conf="linux+release" />
> <artifact name="art1d" type="so" conf="linux+debug" />
> I can absolutely attest that I have a real-world business case that doesn't
> involve cute pets or cute coffee drinks where, if I'm not able to express
> something like "windows+release" on a publication, I'm stuck between a rock
> and a hard place:
> *    Rock: If I'm forced to create combination Ivy confs like
> "windows-and-release", my Ivy module descriptors become totally
> unmaintainable really fast.
> *    Hard place: If I have to rely on consumer Ivy modules knowing to
> express their dependencies using "windows+release" (with all the
> communication that involves), then whenever a consumer Ivy module
> mistakenly
> does "windows,release", my deployment is hosed.
> Now, someone might argue, "It's ambiguous how configuration intersections
> affect transitive dependencies." And I say to that, not so. It would be
> easy
> enough to do a logical proof that configuration intersections like
> "windows+release" would behave no differently than manufactured composite
> configurations like "windows-and-release".
> Someone might also argue that intersections are too restrictive and will
> get
> too few artifacts. And to that I say, restrictiveness is the whole point.
> Who is anyone but the module publisher to know what is too restrictive?
> There is one counterargument I am sympathetic to. If the configurations
> section of a module descriptor is considered the Ivy module's sole
> interface, then configuration intersections, as something that would be
> expressed only in the publications section, are not part of the interface.
> But that train has already left the station. If we allow configuration
> intersections on dependencies, then we're already expressing a request that
> goes beyond the configurations section; we're already saying we've taken a
> peek at the publications section.
> Still, I'm sympathetic to that argument. And I think the ideal solution
> would be to acknowledge that Ivy confs, as originally conceived, are not
> composite constructs; so we need to introduce composite elements that can
> be
> used to construct confs. Frankly, though, I'd rather not wait for the ideal
> solution.
> I'm hoping it's not too late for the simple fix of allowing + notation on
> artifact confs to get incorporated into Ivy 2.1 before its final release.
> And since the JIRA issue IVY1093 is not yet resolved, I'm thinking this
> change would be a natural fit to just incorporate into that fix.
> I will be more than happy to open a JIRA issue for this problem, but I
> definitely will like to know your opinion on this before I do open one.
> Regards,
> Garima.
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.

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