1. Yes, I agree that adding what Garima wants will not compromise my use case. I just haven't been convinced why Garima is requesting this. Either Garima is not understanding configurations in general (which might be the case as Garima admitted not knowing about the '@' character) or you are not understanding configurations in general (which might be the case based on your comment that "windows,debug" is inaccurate) or I am not understanding your use case.
2. "The following, by itself, is inaccurate: <artifact name="art1d" type="dll" conf="windows,debug" />" How can you say this is inaccurate? I am thinking you are getting confused about configurations (or maybe I am). The conf attribute of an artifact is simply a comma delimited list of all configuration names that this artifact is applicable for. The art1d.dll is a windows related file so it is definitely applicable for the windows configuration. The art1d.dll is a debug version of the dll so it is definitely applicable for the debug configuration. The "windows,debug" does NOT mean union in this section of the ivy.xml file where the artifacts are defined. It is in the <dependencies? section of the ivy.xml file where "windows,debug" would mean union. So the comma notation of configurations means two different things depending on what section of the ivy.xml you are talking about. In the <publications> section, the comma doesn't mean anything. It is just a delimiter separating configuration names for all of the configurations that this artifact is applicable for. In the <dependencies> section, the conf mapping attribute like "default->windows,debug" means the default configuration of my current module is dependent on BOTH (UNION) of the windows and debug configurations of the dependent module. IVY configurations are just a way to subset all the artifacts of a module since you may not want all artifacts of a module all the time. Sometimes you just want all windows artifacts so you would use the conf mapping in the <dependencies> section as "default->windows". Sometimes you just want all debug artifacts so you would use the conf mapping in the <dependencies> section as "default->debug". Sometimes you just want the windows debug artifacts so you would use the new intersection capability in the <dependencies> section as "default->windows+debug". It is purely a download efficiency enhancement for me. Before the intersection capability, I would have to use "default->windows" and then manually delete the non-debug artifacts. But even with that, I had to wait for IVY to download them into the cache. Over a slow network line, this can waste a lot of time for artifacts that are just going to be deleted manually. I don't understand Garima's request as putting the intersection logic into the <publications> section of the ivy.xml file like: <artifact name="art1d" type="dll" conf="windows+debug"/> means that the ONLY way a consumer can get this artifact is by specifying "default->windows+debug" in the <dependencies> section. This prevents me from getting all windows artifacts or all debug artifacts. It just doesn't make sense to me. --- Shawn Castrianni -----Original Message----- From: Mitch Gitman [mailto:[email protected]] Sent: Wednesday, July 29, 2009 4:07 PM To: [email protected] Subject: Re: feature request: configuration intersections only implemented halfway I would heartily second Garima's feature request. I'll describe below a potential error condition with the way configuration intersections are implemented now. It looks to me like adding what she's asking for in no way compromises the functionality Shawn already enjoys. It just more explicitly, clearly, and robustly enforces the contract involved in intersections--and prevents the error I'll describe shortly. Shawn, a question for you. Would you agree that merely *allowing *intersections on the *artifact *element--while still supporting the existing behavior--in no way compromises what you're already able to accomplish? And a question for Maarten or Xavier. What is the proper channel to go through for requesting a new feature in Ivy? Few responses to Shawn inline... On Wed, Jul 29, 2009 at 11:39 AM, Shawn Castrianni < [email protected]> 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. > Shawn, this may be a precious distinction. But what I think Garima is trying to say is that, *strictly on the face of it*, "windows+debug" is useless and meaningless when the artifact is specified as "windows,debug". It's only by doing the exercise of going through the artifacts and producing the intersection that you're able to obtain just that one file, art1d.dll. So this brings me to the error condition. If the client were to specify "windows,debug", they would get something that, in your own example, is incorrect. Therefore, you're relying on the consumer to specify things correctly. What troubles me is that you can have an *artifact *specification that, standing by itself, is inaccurate. The following, by itself, is inaccurate: <artifact name="art1d" type="dll" conf="windows,debug" /> This artifact should not be available in the union of windows and debug but it is. Shawn, would you agree with that narrow statement? > > > 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, I appreciate that Garima's message was a lot to digest. But it looks like you're grabbing a bit of devil's advocacy and taking it out of context. I think Garima has made it clear as day that she too believes configuration intersections are a great and necessary feature and that the idea of removing it is not the path she wants to go down. It so happens that I myself am facing a real-world use case for configuration intersections and that I myself find the current support for the feature overly complex and an invitation for trouble. Maybe this is an admission that I'm not too bright, but I would hate to have to look at a single *artifact *element, see the union of confs, and not be aware that the artifact actually should *not *be delivered in that situation--and that I'm going to have to go through a little mathematical exercise to figure out what should be delivered when. > > > --- > Shawn Castrianni > > ---------------------------------------------------------------------- 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.
