ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: feature request: configuration intersections only implemented halfway
Date Wed, 29 Jul 2009 22:15:02 GMT
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.
Mime
View raw message