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 [mailto:garima.bat...@gmail.com] Sent: Wednesday, July 29, 2009 1:11 PM To: ivy-user@ant.apache.org 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 art1d.so, 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.
