You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Mitch Gitman <mg...@gmail.com> on 2009/07/29 23:06:33 UTC
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 <
Shawn.Castrianni@halliburton.com> 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
>
>
Re: feature request: configuration intersections only implemented halfway
Posted by Niklas Matthies <ml...@nmhq.net>.
On Wed 2009-07-29 at 23:22h, Garima Bathla wrote on ivy-user:
:
> So I need to come up with a palette of Ivy confs and a combination of them
> to specify to deliver me the following artifacts:
> mocha.jar
> mocha-tall.jar
> mocha-tall-iced.jar
>
> Well, I know how to do this the hard way:
> <conf name="mocha" />
> <conf name="mocha-tall" extends="mocha" />
> <conf name="mocha-tall-iced" extends="mocha-tall" />
>
> Then in my dependency module, I would ask for "mocha-tall-iced". Only
> problem: now I'm stuck with 4+16+32 Ivy confs. There's got to be a better
> way. (Again, I realize that I'm producing a proliferation of artifacts
> regardless.)
Isn't the number of additional confs just proportional to the number
of those special artifacts though? If yes, then this means you have
only O(1) of extra work to do for each such artifact, so to speak.
No extra combinatorial explosion. Or am I missing something?
I'm still curious what the real (non-coffee) domain context is. ;)
-- Niklas Matthies
Re: feature request: configuration intersections only implemented
halfway
Posted by Garima Bathla <ga...@gmail.com>.
Thank you all for actively pursuing this issue. I need to take a step back
from my feature request for a moment, because I just realized my situation
is even more complicated than I had thought.
Forgive me for going back to my coffee analogy. In addition to something
like mocha-tall-iced.jar that I only want delivered in that combination
situation, I also have something like mocha-tall.jar that I simultaneously
want delivered whether it's iced or hot. And to top all that off, I also
have something called mocha.jar that I likewise simultaneously want
delivered regardless of the size or temperature.
So I need to come up with a palette of Ivy confs and a combination of them
to specify to deliver me the following artifacts:
mocha.jar
mocha-tall.jar
mocha-tall-iced.jar
Well, I know how to do this the hard way:
<conf name="mocha" />
<conf name="mocha-tall" extends="mocha" />
<conf name="mocha-tall-iced" extends="mocha-tall" />
Then in my dependency module, I would ask for "mocha-tall-iced". Only
problem: now I'm stuck with 4+16+32 Ivy confs. There's got to be a better
way. (Again, I realize that I'm producing a proliferation of artifacts
regardless.)
It may very well be that I wind up doing some serious re-factoring and get
rid of one of my dimensions. I'll also take a second look at configuration
groupings.
Regards,
Garima.
On Wed, Jul 29, 2009 at 4:09 PM, Mitch Gitman <mg...@gmail.com> wrote:
> Shawn, I think your last paragraph really captures the fundamental
> difference between your use case and the one I'm facing (which parallels
> the
> use case Garima broached):
> 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.
>
> For me, being able to get "ALL Windows artifacts" or "ALL Windows OR debug
> artifacts" would be at best an academic exercise. As a practical matter,
> though, the simple ability to do this is trouble. The simple inability to
> express intersection-only means that I can't communicate in Ivy the true
> semantics of my Ivy module.
>
> In other words, I really do have artifacts that should only be available in
> the intersection of certain confs of their Ivy module. Being able to get
> unions containing these particular artifacts does me no good, but it does
> potentially do me harm.
>
> To put things in simple terms, what Shawn asked for was to make the
> following possible on the *consumer *Ivy module:
> if (A && B)
> In addition to:
> if (A || B)
>
> What Garima is asking for—and what I'm seconding—is to make the same
> possible on the *producer *Ivy module.
>
> On Wed, Jul 29, 2009 at 3:15 PM, Shawn Castrianni <
> Shawn.Castrianni@halliburton.com> wrote:
>
> > 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
> >
> >
>
Re: feature request: configuration intersections only implemented
halfway
Posted by Mitch Gitman <mg...@gmail.com>.
Shawn, I think your last paragraph really captures the fundamental
difference between your use case and the one I'm facing (which parallels the
use case Garima broached):
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.
For me, being able to get "ALL Windows artifacts" or "ALL Windows OR debug
artifacts" would be at best an academic exercise. As a practical matter,
though, the simple ability to do this is trouble. The simple inability to
express intersection-only means that I can't communicate in Ivy the true
semantics of my Ivy module.
In other words, I really do have artifacts that should only be available in
the intersection of certain confs of their Ivy module. Being able to get
unions containing these particular artifacts does me no good, but it does
potentially do me harm.
To put things in simple terms, what Shawn asked for was to make the
following possible on the *consumer *Ivy module:
if (A && B)
In addition to:
if (A || B)
What Garima is asking for—and what I'm seconding—is to make the same
possible on the *producer *Ivy module.
On Wed, Jul 29, 2009 at 3:15 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> 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
>
>
RE: feature request: configuration intersections only implemented
halfway
Posted by Shawn Castrianni <Sh...@halliburton.com>.
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:mgitman@gmail.com]
Sent: Wednesday, July 29, 2009 4:07 PM
To: ivy-user@ant.apache.org
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 <
Shawn.Castrianni@halliburton.com> 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.