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 Garima Bathla <ga...@gmail.com> on 2009/07/27 22:19:39 UTC
multiple artifact confs: wanting AND instead of OR
Suppose my Ivy module descriptor (ivy.xml) has an
/ivy-module/publications/artifact element like so:
<artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
"dachshund,persian"* />
Now, what this means is that cute-dog-and-cat.jar will be grabbed if EITHER
the dachshund conf or the persian conf is requested. What I would have liked
it to mean instead is that the JAR will be grabbed only if BOTH the
dachshund conf and persian conf are requested.
So I wonder if there's some way for an artifact to be resolved only if an
entire combination of two or more Ivy confs is requested. This way I could
express my dependency on this module with dachshund,persian rather than
having to create a bogus combo Ivy conf, dachshund-persian.
If I had to describe the generalization of my situation, I would say it's
where the Ivy module has a preponderance of artifacts, each of which is
needed in a Cartesian product situation, and I want to be able to use a
Cartesian product of Ivy confs rather than have to create special "Cartesian
product Ivy confs."
Regards,
Garima.
Re: multiple artifact confs: wanting AND instead of OR
Posted by Niklas Matthies <ml...@nmhq.net>.
On Mon 2009-07-27 at 21:17h, Mitch Gitman wrote on ivy-user:
:
> The problem is you can't specify the intersection on the artifacts:
> <artifact name="mocha-short-hot" type="jar" conf="mocha+short+hot" />
>
> The onus is on the consumer (the dependent Ivy module) to specify the
> intersection and not the union.
Which, by the way, is dangerous, because the published module has no
way to specify which intersections are expected to work and which
don't. It's a bit analogous to intersecting two class implementations
because you only need their common interface, and hoping that this
intersection still works in any sensible way.
It also doesn't scale to transitive dependencies, see:
http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200904.mbox/%3c20090415170945.GC68410@nmhq.net%3e
Personally I wonder what the actual use cases are of having artifacts
that are only valid for a particular combination of configurations,
where an explicit combination configuration or separate modules
wouldn't be a better solution. The cute pet or the coffee drink
examples don't make any sense to me. ;)
-- Niklas Matthies
Re: multiple artifact confs: wanting AND instead of OR
Posted by Niklas Matthies <ml...@nmhq.net>.
On Tue 2009-07-28 at 09:13h, Mitch Gitman wrote on ivy-user:
> Shawn, nice explanation how configuration grouping can be used to do
> intersection. Essentially, if I understand correctly, it all comes down to
> the use of the @ (at sign). And thanks for explaining what the @ means. Does
> anyone happen to know where in the Ivy documentation that is documented and
> what version of Ivy it was introduced with?
It was introduced with Ivy 1.2, according to the documentation:
http://ant.apache.org/ivy/history/trunk/ivyfile/dependency.html
:
> And can anyone point me toward the documentation for adding an ext:grouping
> or e:grouping attribute to a conf? I'm most curious about the XML schema
> namespace that the ext or e prefix gets mapped to.
You can use any extra attribute for grouping.
See http://ant.apache.org/ivy/history/trunk/concept.html#extra for
general information about extra attributes.
-- Niklas Matthies
Re: multiple artifact confs: wanting AND instead of OR
Posted by Mitch Gitman <mg...@gmail.com>.
Shawn, nice explanation how configuration grouping can be used to do
intersection. Essentially, if I understand correctly, it all comes down to
the use of the @ (at sign). And thanks for explaining what the @ means. Does
anyone happen to know where in the Ivy documentation that is documented and
what version of Ivy it was introduced with? Because frankly, even though I
consider myself a sophisticated Ivy user, that @ feature wasn't on my radar
screen.
And can anyone point me toward the documentation for adding an ext:grouping
or e:grouping attribute to a conf? I'm most curious about the XML schema
namespace that the ext or e prefix gets mapped to.
On Mon, Jul 27, 2009 at 10:36 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> Correct, I didn't mean to imply that configuration grouping would help
> Garima's problem. I was trying to describe what configuration intersections
> and groupings features provide to see if Garima really needs what Garima is
> requesting. It does sound like intersection on the artifacts is being
> requested and I don't think that was implemented with my feature request. I
> asked what is the reason Garima needs intersection on the artifacts and I
> still don't think I understand the necessity for it.
>
>
> I disagree that configuration groupings give you union and not
> intersection. Configuration grouping give you the ability to use wildcard
> in configuration mappings with intersections. Here is an example:
>
>
> 1. Say you have 3 modules A->B->C.
> 2. Say all three modules have configurations that subdivide each of them
> based on the grouping called "platform" where the configurations within the
> platform grouping can be windows, linux, or solaris. The syntax for each of
> these three modules configuration section would be:
>
> <configurations>
> <conf name="windows" ext:grouping="platform"/>
> <conf name="linux" ext:grouping="platform"/>
> <conf name="solaris" ext:grouping="platform"/>
> </configurations>
>
> 3. Say that module B also has another grouping called "quality" that
> subdivides its artifacts in a different way based on release type where the
> configurations within the quality grouping can be release or debug. The
> additional syntax of the configurations section or module B would be:
>
> <configurations>
> <conf name="windows" ext:grouping="platform"/>
> <conf name="linux" ext:grouping="platform"/>
> <conf name="solaris" ext:grouping="platform"/>
>
> <conf name="release" ext:grouping="quality"/>
> <conf name="debug" ext:grouping="quality"/>
> </configurations>
>
> 4. Say A has declared a dependency on B to match the platform requested of
> A but intersected with the release quality. That syntax would be:
>
> <dependencies>
> <dependency name="B" rev="latest.integration" conf="*->@+release"/>
> </dependencies>
>
> This configuration mapping is read, "Whichever of the three configurations
> in A that is requested for resolution, match that to the same named
> configuration in B and then intersect that with the release configuration in
> B. This keeps us on the same platform as requested in A, but only gives us
> the release quality artifacts
>
> 5. Now I haven't used the grouping feature yet. So far this has just used
> the configuration intersection feature. The grouping part comes in handy in
> the configuration mapping between B and C. C does not have the quality
> grouping configurations release or debug, so the configuration mapping
> "*->@" would not work and would yield an error stating that release
> configuration does not exist in module C. So to keep the same platform but
> throw away the dependence on the release configuration name for C, the
> configuration mapping between B and C would be:
>
> <dependencies>
> <dependency name="C" rev="latest.integration"
> conf="*[grouping=platform]->@;*[grouping=quality]->*"/>
> </dependencies>
>
> This was the hardest part for me to understand from the developer who
> implemented this feature for me. This configuration mapping is read,
> "Whichever of the 3 configurations in the platform grouping that is
> requested for resolution, match that to the same named configuration in C
> which has these same 3 configuration names AND whichever of the 2
> configurations in the quality grouping that is requested for resolution,
> match that to all of the configurations in C". By matching the quality
> configurations in B to all configurations in C, the quality configurations
> do not have to exist in C.
>
>
> I realize this is very hard to understand over an email description. I
> find this to be very useful and applicable in many situations. I have
> tested this in the latest IVY build and it works great.
>
> ---
> Shawn Castrianni
>
> -----Original Message-----
> From: Mitch Gitman [mailto:mgitman@gmail.com]
> Sent: Monday, July 27, 2009 11:17 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> Shawn, these are some great insights you're offering, but I don't see how
> configuration groupings would help in the situation Garima's describing.
> See
> the example with the JIRA issue:
> https://issues.apache.org/jira/browse/IVY-1097
>
> Quote: "In this ivy file, *[axis=platform] is equivalent to windows,linux"
> So this...:
> <artifact name="art51A" type="jar" conf="A,*[axis=platform]" />
> ...is equivalent to this:
> <artifact name="art51A" type="jar" conf="A,windows,linux" />
>
> In other words, configuration groups/groupings give you union, not
> intersection.
>
> The closest I can come to accomplishing what Garima's requesting is this:
> ...
> <configurations>
> <conf name="mocha" />
> <conf name="latte" />
> <conf name="cappuccino" />
> <conf name="americano" />
>
> <conf name="short" />
> <conf name="tall" />
> <conf name="grande" />
> <conf name="venti" />
>
> <conf name="hot" />
> <conf name="iced" />
> </configurations>
>
> <publications>
> <artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
> ...
>
> The problem is you can't specify the intersection on the artifacts:
> <artifact name="mocha-short-hot" type="jar" conf="mocha+short+hot" />
>
> The onus is on the consumer (the dependent Ivy module) to specify the
> intersection and not the union.
>
> I would vote that it's worth implementing the feature of offering
> configuration intersections on publishable artifacts, in addition to
> dependencies. Why?
>
> Simply for the reason that the following does not accurately describe the
> artifact's publishable configuration:
> <artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
> And having to create a composite Ivy conf for every possible permutation is
> a fragile hack.
>
>
RE: multiple artifact confs: wanting AND instead of OR
Posted by Shawn Castrianni <Sh...@halliburton.com>.
Correct, I didn't mean to imply that configuration grouping would help Garima's problem. I was trying to describe what configuration intersections and groupings features provide to see if Garima really needs what Garima is requesting. It does sound like intersection on the artifacts is being requested and I don't think that was implemented with my feature request. I asked what is the reason Garima needs intersection on the artifacts and I still don't think I understand the necessity for it.
I disagree that configuration groupings give you union and not intersection. Configuration grouping give you the ability to use wildcard in configuration mappings with intersections. Here is an example:
1. Say you have 3 modules A->B->C.
2. Say all three modules have configurations that subdivide each of them based on the grouping called "platform" where the configurations within the platform grouping can be windows, linux, or solaris. The syntax for each of these three modules configuration section would be:
<configurations>
<conf name="windows" ext:grouping="platform"/>
<conf name="linux" ext:grouping="platform"/>
<conf name="solaris" ext:grouping="platform"/>
</configurations>
3. Say that module B also has another grouping called "quality" that subdivides its artifacts in a different way based on release type where the configurations within the quality grouping can be release or debug. The additional syntax of the configurations section or module B would be:
<configurations>
<conf name="windows" ext:grouping="platform"/>
<conf name="linux" ext:grouping="platform"/>
<conf name="solaris" ext:grouping="platform"/>
<conf name="release" ext:grouping="quality"/>
<conf name="debug" ext:grouping="quality"/>
</configurations>
4. Say A has declared a dependency on B to match the platform requested of A but intersected with the release quality. That syntax would be:
<dependencies>
<dependency name="B" rev="latest.integration" conf="*->@+release"/>
</dependencies>
This configuration mapping is read, "Whichever of the three configurations in A that is requested for resolution, match that to the same named configuration in B and then intersect that with the release configuration in B. This keeps us on the same platform as requested in A, but only gives us the release quality artifacts
5. Now I haven't used the grouping feature yet. So far this has just used the configuration intersection feature. The grouping part comes in handy in the configuration mapping between B and C. C does not have the quality grouping configurations release or debug, so the configuration mapping "*->@" would not work and would yield an error stating that release configuration does not exist in module C. So to keep the same platform but throw away the dependence on the release configuration name for C, the configuration mapping between B and C would be:
<dependencies>
<dependency name="C" rev="latest.integration" conf="*[grouping=platform]->@;*[grouping=quality]->*"/>
</dependencies>
This was the hardest part for me to understand from the developer who implemented this feature for me. This configuration mapping is read, "Whichever of the 3 configurations in the platform grouping that is requested for resolution, match that to the same named configuration in C which has these same 3 configuration names AND whichever of the 2 configurations in the quality grouping that is requested for resolution, match that to all of the configurations in C". By matching the quality configurations in B to all configurations in C, the quality configurations do not have to exist in C.
I realize this is very hard to understand over an email description. I find this to be very useful and applicable in many situations. I have tested this in the latest IVY build and it works great.
---
Shawn Castrianni
-----Original Message-----
From: Mitch Gitman [mailto:mgitman@gmail.com]
Sent: Monday, July 27, 2009 11:17 PM
To: ivy-user@ant.apache.org
Subject: Re: multiple artifact confs: wanting AND instead of OR
Shawn, these are some great insights you're offering, but I don't see how
configuration groupings would help in the situation Garima's describing. See
the example with the JIRA issue:
https://issues.apache.org/jira/browse/IVY-1097
Quote: "In this ivy file, *[axis=platform] is equivalent to windows,linux"
So this...:
<artifact name="art51A" type="jar" conf="A,*[axis=platform]" />
...is equivalent to this:
<artifact name="art51A" type="jar" conf="A,windows,linux" />
In other words, configuration groups/groupings give you union, not
intersection.
The closest I can come to accomplishing what Garima's requesting is this:
...
<configurations>
<conf name="mocha" />
<conf name="latte" />
<conf name="cappuccino" />
<conf name="americano" />
<conf name="short" />
<conf name="tall" />
<conf name="grande" />
<conf name="venti" />
<conf name="hot" />
<conf name="iced" />
</configurations>
<publications>
<artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
...
The problem is you can't specify the intersection on the artifacts:
<artifact name="mocha-short-hot" type="jar" conf="mocha+short+hot" />
The onus is on the consumer (the dependent Ivy module) to specify the
intersection and not the union.
I would vote that it's worth implementing the feature of offering
configuration intersections on publishable artifacts, in addition to
dependencies. Why?
Simply for the reason that the following does not accurately describe the
artifact's publishable configuration:
<artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
And having to create a composite Ivy conf for every possible permutation is
a fragile hack.
On Mon, Jul 27, 2009 at 4:44 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> That is exactly why I requested configuration intersection support. See my
> previous post to this email group. Here is a URL that points to it:
>
>
> http://www.nabble.com/configuration-help-td23049370.html
>
>
> The configuration grouping would then allow you to set up 3 groups:
>
> flavor
> size
> temperature
>
> Where the:
>
> flavor group contains (mocha, latte, cappuccino, Americano)
> size group contains (short, tall, grande, venti)
> temperature group contains (hot, iced)
>
> then these groups come in handy when you specify your configuration mapping
> using wildcards. The IVY-1097 shows what this wildcard notation looks like.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 6:05 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> PS : Sorry for this lengthy example - I couldn't any other better
> sophisticated way to explain it.
>
> Shawn, you're interpreting this correctly.
>
> I think putting the + intersection notation on the dependency gives part of
> what I'm looking for. If I express a dependency like so, then I will only
> get art1d.dll:
> <dependency ... conf="default->windows+debug" />
>
> Then at least I know that at the dependent module level, I'm able to
> restrict the dependency. But then at the publishing module level, I'm
> really
> trusting the dependent module to request "windows+debug" and not just
> "windows" or "debug" if I want art1dll.dll to be delivered only in the
> windows+debug combination.
>
> Here's the answer to your question: "I don't see any benefit to this as it
> seems to be the same as just another configuration name. Maybe if you
> elaborated on why you need this?"
>
> Actually, the problem is that it is just another configuration name.
> Suppose
> my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
>
> - mocha-short-hot
> - mocha-tall-hot
> - mocha-grande-hot
> - mocha-venti-hot
> - mocha-short-iced
> - mocha-tall-iced
> - mocha-grande-iced
> - mocha-venti-iced
> - latte-short-hot
> - latte-tall-hot
> - latte-grande-hot
> - latte-venti-hot
> - latte-short-iced
> - latte-tall-iced
> - latte-grande-iced
> - latte-venti-iced
> - cappuccino-short-hot
> - cappuccino-tall-hot
> - cappuccino-grande-hot
> - cappuccino-venti-hot
> - cappuccino-short-iced
> - cappuccino-tall-iced
> - cappuccino-grande-iced
> - cappuccino-venti-iced
> - americano-short-hot
> - americano-tall-hot
> - americano-grande-hot
> - americano-venti-hot
> - americano-short-iced
> - americano-tall-iced
> - americano-grande-iced
> - americano-venti-iced
>
> I would hate to have to create 32 different Ivy confs when I could get away
> with just 4+4+2=10:
>
> - mocha
> - latte
> - cappuccino
> - americano
>
>
> - short
> - tall
> - grande
> - venti
>
>
> - hot
> - iced
>
> 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.
Re: multiple artifact confs: wanting AND instead of OR
Posted by Mitch Gitman <mg...@gmail.com>.
Shawn, these are some great insights you're offering, but I don't see how
configuration groupings would help in the situation Garima's describing. See
the example with the JIRA issue:
https://issues.apache.org/jira/browse/IVY-1097
Quote: "In this ivy file, *[axis=platform] is equivalent to windows,linux"
So this...:
<artifact name="art51A" type="jar" conf="A,*[axis=platform]" />
...is equivalent to this:
<artifact name="art51A" type="jar" conf="A,windows,linux" />
In other words, configuration groups/groupings give you union, not
intersection.
The closest I can come to accomplishing what Garima's requesting is this:
...
<configurations>
<conf name="mocha" />
<conf name="latte" />
<conf name="cappuccino" />
<conf name="americano" />
<conf name="short" />
<conf name="tall" />
<conf name="grande" />
<conf name="venti" />
<conf name="hot" />
<conf name="iced" />
</configurations>
<publications>
<artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
...
The problem is you can't specify the intersection on the artifacts:
<artifact name="mocha-short-hot" type="jar" conf="mocha+short+hot" />
The onus is on the consumer (the dependent Ivy module) to specify the
intersection and not the union.
I would vote that it's worth implementing the feature of offering
configuration intersections on publishable artifacts, in addition to
dependencies. Why?
Simply for the reason that the following does not accurately describe the
artifact's publishable configuration:
<artifact name="mocha-short-hot" type="jar" conf="mocha,short,hot" />
And having to create a composite Ivy conf for every possible permutation is
a fragile hack.
On Mon, Jul 27, 2009 at 4:44 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> That is exactly why I requested configuration intersection support. See my
> previous post to this email group. Here is a URL that points to it:
>
>
> http://www.nabble.com/configuration-help-td23049370.html
>
>
> The configuration grouping would then allow you to set up 3 groups:
>
> flavor
> size
> temperature
>
> Where the:
>
> flavor group contains (mocha, latte, cappuccino, Americano)
> size group contains (short, tall, grande, venti)
> temperature group contains (hot, iced)
>
> then these groups come in handy when you specify your configuration mapping
> using wildcards. The IVY-1097 shows what this wildcard notation looks like.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 6:05 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> PS : Sorry for this lengthy example - I couldn't any other better
> sophisticated way to explain it.
>
> Shawn, you're interpreting this correctly.
>
> I think putting the + intersection notation on the dependency gives part of
> what I'm looking for. If I express a dependency like so, then I will only
> get art1d.dll:
> <dependency ... conf="default->windows+debug" />
>
> Then at least I know that at the dependent module level, I'm able to
> restrict the dependency. But then at the publishing module level, I'm
> really
> trusting the dependent module to request "windows+debug" and not just
> "windows" or "debug" if I want art1dll.dll to be delivered only in the
> windows+debug combination.
>
> Here's the answer to your question: "I don't see any benefit to this as it
> seems to be the same as just another configuration name. Maybe if you
> elaborated on why you need this?"
>
> Actually, the problem is that it is just another configuration name.
> Suppose
> my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
>
> - mocha-short-hot
> - mocha-tall-hot
> - mocha-grande-hot
> - mocha-venti-hot
> - mocha-short-iced
> - mocha-tall-iced
> - mocha-grande-iced
> - mocha-venti-iced
> - latte-short-hot
> - latte-tall-hot
> - latte-grande-hot
> - latte-venti-hot
> - latte-short-iced
> - latte-tall-iced
> - latte-grande-iced
> - latte-venti-iced
> - cappuccino-short-hot
> - cappuccino-tall-hot
> - cappuccino-grande-hot
> - cappuccino-venti-hot
> - cappuccino-short-iced
> - cappuccino-tall-iced
> - cappuccino-grande-iced
> - cappuccino-venti-iced
> - americano-short-hot
> - americano-tall-hot
> - americano-grande-hot
> - americano-venti-hot
> - americano-short-iced
> - americano-tall-iced
> - americano-grande-iced
> - americano-venti-iced
>
> I would hate to have to create 32 different Ivy confs when I could get away
> with just 4+4+2=10:
>
> - mocha
> - latte
> - cappuccino
> - americano
>
>
> - short
> - tall
> - grande
> - venti
>
>
> - hot
> - iced
>
> Regards,
> Garima.
>
>
RE: multiple artifact confs: wanting AND instead of OR
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I don't think that was implemented for my intersection enhancement request, so you will have to request that separately.
---
Shawn Castrianni
-----Original Message-----
From: Garima Bathla [mailto:garima.bathla@gmail.com]
Sent: Tuesday, July 28, 2009 12:12 PM
To: ivy-user@ant.apache.org
Subject: Re: multiple artifact confs: wanting AND instead of OR
Shawn, let's just say that, for argument's sake, I did the grouping like so:
<configurations>
<conf name="windows" grouping="platform" />
<conf name="linux" grouping="platform" />
<conf name="release" grouping="quality" />
<conf name="debug" grouping="quality" />
</configurations>
How would I be able to express the equivalent of the following in the
publishing Ivy module and not in an Ivy module that depends on it?:
<artifact name="art1d" type="dll" conf="windows+debug" />
The problem is the following is not accurate; it's too permissive:
<artifact name="art1d" type="dll" conf="windows,debug" />
In other words-with Ivy as it now is rather than how I might want it to
be-how can I say that a given artifact should be delivered only for a given
combination/intersection of configurations? The goal is to avoid having to
parallel my proliferation of artifacts (which I can't avoid) with a
proliferation of Ivy confs, especially when those confs are nothing more
than bogus Cartesian product confs.
Regards,
Garima.
On Mon, Jul 27, 2009 at 4:44 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> That is exactly why I requested configuration intersection support. See my
> previous post to this email group. Here is a URL that points to it:
>
>
> http://www.nabble.com/configuration-help-td23049370.html
>
>
> The configuration grouping would then allow you to set up 3 groups:
>
> flavor
> size
> temperature
>
> Where the:
>
> flavor group contains (mocha, latte, cappuccino, Americano)
> size group contains (short, tall, grande, venti)
> temperature group contains (hot, iced)
>
> then these groups come in handy when you specify your configuration mapping
> using wildcards. The IVY-1097 shows what this wildcard notation looks like.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 6:05 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> PS : Sorry for this lengthy example - I couldn't any other better
> sophisticated way to explain it.
>
> Shawn, you're interpreting this correctly.
>
> I think putting the + intersection notation on the dependency gives part of
> what I'm looking for. If I express a dependency like so, then I will only
> get art1d.dll:
> <dependency ... conf="default->windows+debug" />
>
> Then at least I know that at the dependent module level, I'm able to
> restrict the dependency. But then at the publishing module level, I'm
> really
> trusting the dependent module to request "windows+debug" and not just
> "windows" or "debug" if I want art1dll.dll to be delivered only in the
> windows+debug combination.
>
> Here's the answer to your question: "I don't see any benefit to this as it
> seems to be the same as just another configuration name. Maybe if you
> elaborated on why you need this?"
>
> Actually, the problem is that it is just another configuration name.
> Suppose
> my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
>
> - mocha-short-hot
> - mocha-tall-hot
> - mocha-grande-hot
> - mocha-venti-hot
> - mocha-short-iced
> - mocha-tall-iced
> - mocha-grande-iced
> - mocha-venti-iced
> - latte-short-hot
> - latte-tall-hot
> - latte-grande-hot
> - latte-venti-hot
> - latte-short-iced
> - latte-tall-iced
> - latte-grande-iced
> - latte-venti-iced
> - cappuccino-short-hot
> - cappuccino-tall-hot
> - cappuccino-grande-hot
> - cappuccino-venti-hot
> - cappuccino-short-iced
> - cappuccino-tall-iced
> - cappuccino-grande-iced
> - cappuccino-venti-iced
> - americano-short-hot
> - americano-tall-hot
> - americano-grande-hot
> - americano-venti-hot
> - americano-short-iced
> - americano-tall-iced
> - americano-grande-iced
> - americano-venti-iced
>
> I would hate to have to create 32 different Ivy confs when I could get away
> with just 4+4+2=10:
>
> - mocha
> - latte
> - cappuccino
> - americano
>
>
> - short
> - tall
> - grande
> - venti
>
>
> - hot
> - iced
>
> 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.
Re: multiple artifact confs: wanting AND instead of OR
Posted by Garima Bathla <ga...@gmail.com>.
Shawn, let's just say that, for argument's sake, I did the grouping like so:
<configurations>
<conf name="windows" grouping="platform" />
<conf name="linux" grouping="platform" />
<conf name="release" grouping="quality" />
<conf name="debug" grouping="quality" />
</configurations>
How would I be able to express the equivalent of the following in the
publishing Ivy module and not in an Ivy module that depends on it?:
<artifact name="art1d" type="dll" conf="windows+debug" />
The problem is the following is not accurate; it's too permissive:
<artifact name="art1d" type="dll" conf="windows,debug" />
In other words—with Ivy as it now is rather than how I might want it to
be—how can I say that a given artifact should be delivered only for a given
combination/intersection of configurations? The goal is to avoid having to
parallel my proliferation of artifacts (which I can't avoid) with a
proliferation of Ivy confs, especially when those confs are nothing more
than bogus Cartesian product confs.
Regards,
Garima.
On Mon, Jul 27, 2009 at 4:44 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> That is exactly why I requested configuration intersection support. See my
> previous post to this email group. Here is a URL that points to it:
>
>
> http://www.nabble.com/configuration-help-td23049370.html
>
>
> The configuration grouping would then allow you to set up 3 groups:
>
> flavor
> size
> temperature
>
> Where the:
>
> flavor group contains (mocha, latte, cappuccino, Americano)
> size group contains (short, tall, grande, venti)
> temperature group contains (hot, iced)
>
> then these groups come in handy when you specify your configuration mapping
> using wildcards. The IVY-1097 shows what this wildcard notation looks like.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 6:05 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> PS : Sorry for this lengthy example - I couldn't any other better
> sophisticated way to explain it.
>
> Shawn, you're interpreting this correctly.
>
> I think putting the + intersection notation on the dependency gives part of
> what I'm looking for. If I express a dependency like so, then I will only
> get art1d.dll:
> <dependency ... conf="default->windows+debug" />
>
> Then at least I know that at the dependent module level, I'm able to
> restrict the dependency. But then at the publishing module level, I'm
> really
> trusting the dependent module to request "windows+debug" and not just
> "windows" or "debug" if I want art1dll.dll to be delivered only in the
> windows+debug combination.
>
> Here's the answer to your question: "I don't see any benefit to this as it
> seems to be the same as just another configuration name. Maybe if you
> elaborated on why you need this?"
>
> Actually, the problem is that it is just another configuration name.
> Suppose
> my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
>
> - mocha-short-hot
> - mocha-tall-hot
> - mocha-grande-hot
> - mocha-venti-hot
> - mocha-short-iced
> - mocha-tall-iced
> - mocha-grande-iced
> - mocha-venti-iced
> - latte-short-hot
> - latte-tall-hot
> - latte-grande-hot
> - latte-venti-hot
> - latte-short-iced
> - latte-tall-iced
> - latte-grande-iced
> - latte-venti-iced
> - cappuccino-short-hot
> - cappuccino-tall-hot
> - cappuccino-grande-hot
> - cappuccino-venti-hot
> - cappuccino-short-iced
> - cappuccino-tall-iced
> - cappuccino-grande-iced
> - cappuccino-venti-iced
> - americano-short-hot
> - americano-tall-hot
> - americano-grande-hot
> - americano-venti-hot
> - americano-short-iced
> - americano-tall-iced
> - americano-grande-iced
> - americano-venti-iced
>
> I would hate to have to create 32 different Ivy confs when I could get away
> with just 4+4+2=10:
>
> - mocha
> - latte
> - cappuccino
> - americano
>
>
> - short
> - tall
> - grande
> - venti
>
>
> - hot
> - iced
>
> Regards,
> Garima.
>
>
RE: multiple artifact confs: wanting AND instead of OR
Posted by Shawn Castrianni <Sh...@halliburton.com>.
That is exactly why I requested configuration intersection support. See my previous post to this email group. Here is a URL that points to it:
http://www.nabble.com/configuration-help-td23049370.html
The configuration grouping would then allow you to set up 3 groups:
flavor
size
temperature
Where the:
flavor group contains (mocha, latte, cappuccino, Americano)
size group contains (short, tall, grande, venti)
temperature group contains (hot, iced)
then these groups come in handy when you specify your configuration mapping using wildcards. The IVY-1097 shows what this wildcard notation looks like.
---
Shawn Castrianni
-----Original Message-----
From: Garima Bathla [mailto:garima.bathla@gmail.com]
Sent: Monday, July 27, 2009 6:05 PM
To: ivy-user@ant.apache.org
Subject: Re: multiple artifact confs: wanting AND instead of OR
PS : Sorry for this lengthy example - I couldn't any other better
sophisticated way to explain it.
Shawn, you're interpreting this correctly.
I think putting the + intersection notation on the dependency gives part of
what I'm looking for. If I express a dependency like so, then I will only
get art1d.dll:
<dependency ... conf="default->windows+debug" />
Then at least I know that at the dependent module level, I'm able to
restrict the dependency. But then at the publishing module level, I'm really
trusting the dependent module to request "windows+debug" and not just
"windows" or "debug" if I want art1dll.dll to be delivered only in the
windows+debug combination.
Here's the answer to your question: "I don't see any benefit to this as it
seems to be the same as just another configuration name. Maybe if you
elaborated on why you need this?"
Actually, the problem is that it is just another configuration name. Suppose
my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
- mocha-short-hot
- mocha-tall-hot
- mocha-grande-hot
- mocha-venti-hot
- mocha-short-iced
- mocha-tall-iced
- mocha-grande-iced
- mocha-venti-iced
- latte-short-hot
- latte-tall-hot
- latte-grande-hot
- latte-venti-hot
- latte-short-iced
- latte-tall-iced
- latte-grande-iced
- latte-venti-iced
- cappuccino-short-hot
- cappuccino-tall-hot
- cappuccino-grande-hot
- cappuccino-venti-hot
- cappuccino-short-iced
- cappuccino-tall-iced
- cappuccino-grande-iced
- cappuccino-venti-iced
- americano-short-hot
- americano-tall-hot
- americano-grande-hot
- americano-venti-hot
- americano-short-iced
- americano-tall-iced
- americano-grande-iced
- americano-venti-iced
I would hate to have to create 32 different Ivy confs when I could get away
with just 4+4+2=10:
- mocha
- latte
- cappuccino
- americano
- short
- tall
- grande
- venti
- hot
- iced
Regards,
Garima.
On Mon, Jul 27, 2009 at 3:02 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> configuration groups and intersections are complimentary. intersections
> gives you the ability to have the following scenario:
>
> module A contains artifacts that support both (windows and linux) platforms
> AND (debug and release) types:
>
> art1.dll, conf="windows,release"
> art1d.dll, conf="windows,debug"
> art1.so, conf="linux,release"
> art1d.so, conf="linux,debug"
>
>
> Then if module B is dependent on module A, B can specify a certain platform
> and a certain release type with an intersection:
>
> A->B (windows) delivers both art1.dll and art1d.dll
> A->B (linux) delivers both art1.so and art1d.so
> A->B (windows+debug) delivers only art1d.dll since it is the only
> artifact that exists in BOTH the windows configuration and the debug
> configuration
> A->B (windows+release) delivers only art1.dll since it is the only
> artifact that exists in BOTH the windows configuration and the release
> configuration
> A->B (linux+debug) delivers only art1d.so since it is the only artifact
> that exists in BOTH the linux configuration and the debug configuration
> A->B (linux+release) delivers only art1d.so since it is the only artifact
> that exists in BOTH the linux configuration and the release configuration
>
>
>
> What you seem to want to do is to specify that an artifact is only valid
> within an intersection. So I think you are wanting to use the "+" notation
> in the artifact section of the ivy.xml instead of the dependencies section
> like I requested. Something like:
>
> art1.dll, conf="windows+release"
> art1d.dll, conf="windows+debug"
> art1.so, conf="linux+release"
> art1d.so, conf="linux+debug"
>
>
> I don't see any benefit to this as it seems to be the same as just another
> configuration name. Maybe if you elaborated on why you need this?
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 4:47 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> Shawn, thanks. I think you're on the right track here. Let me make sure I'm
> not confused in my understanding: configuration intersections (JIRA
> IVY-1093) are NOT to be confused with configuration groups (JIRA IVY-1097).
>
> Actually, it sounds like configuration intersections may be precisely what
> I'm looking for. Can you provide an example of its usage? I'm guessing you
> might have something like:
> <dependency ... conf="default->dachshund+persian" />
>
> I'll take your word that this has been implemented in 2.1.0-rc2, even
> though
> the JIRA issue hasn't been resolved yet.
>
> I had taken a look at configuration groups and it didn't seem like that
> would help. To use the example on
> https://issues.apache.org/jira/browse/IVY-1097, take the following
> publication artifact:
> <artifact name="art51A" type="jar"
> conf="A,*[axis=platform]"/>
>
> I'm supposing that, if only the A conf was requested when that module was
> specified as a dependency, art51A.jar would be delivered. And if only a
> platform conf like windows was requested in the dependency, art51A.jar
> would
> still be delivered. So it would be the EITHER/OR behavior when really I
> want
> the BOTH/AND behavior. Am I interpreting that correctly?
>
>
> On Mon, Jul 27, 2009 at 2:07 PM, Shawn Castrianni <
> Shawn.Castrianni@halliburton.com> wrote:
>
> > There might be a way to use the new "configuration intersection" feature
> I
> > requested several months ago. It is available in the latest IVY
> 2.1.0-rc2
> > release. It wasn't designed to do exactly what you requested, but might
> be
> > helpful. See the IVY website under release notes which reference
> IVY-1093<
> > https://issues.apache.org/jira/browse/IVY-1093> and IVY-1097<
> > https://issues.apache.org/jira/browse/IVY-1097>.
> >
> >
> >
> > ---
> >
> > Shawn Castrianni
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Garima Bathla [mailto:garima.bathla@gmail.com]
> > Sent: Monday, July 27, 2009 3:20 PM
> > To: ivy-user@ant.apache.org
> > Subject: multiple artifact confs: wanting AND instead of OR
> >
> >
> >
> > Suppose my Ivy module descriptor (ivy.xml) has an
> >
> > /ivy-module/publications/artifact element like so:
> >
> >
> >
> > <artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
> >
> > "dachshund,persian"* />
> >
> >
> >
> > Now, what this means is that cute-dog-and-cat.jar will be grabbed if
> EITHER
> >
> > the dachshund conf or the persian conf is requested. What I would have
> > liked
> >
> > it to mean instead is that the JAR will be grabbed only if BOTH the
> >
> > dachshund conf and persian conf are requested.
> >
> >
> >
> > So I wonder if there's some way for an artifact to be resolved only if an
> >
> > entire combination of two or more Ivy confs is requested. This way I
> could
> >
> > express my dependency on this module with dachshund,persian rather than
> >
> > having to create a bogus combo Ivy conf, dachshund-persian.
> >
> >
> >
> > If I had to describe the generalization of my situation, I would say it's
> >
> > where the Ivy module has a preponderance of artifacts, each of which is
> >
> > needed in a Cartesian product situation, and I want to be able to use a
> >
> > Cartesian product of Ivy confs rather than have to create special
> > "Cartesian
> >
> > product Ivy confs."
> >
> >
> >
> >
> >
> > 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.
> >
>
Re: multiple artifact confs: wanting AND instead of OR
Posted by Garima Bathla <ga...@gmail.com>.
PS : Sorry for this lengthy example - I couldn't any other better
sophisticated way to explain it.
Shawn, you're interpreting this correctly.
I think putting the + intersection notation on the dependency gives part of
what I'm looking for. If I express a dependency like so, then I will only
get art1d.dll:
<dependency ... conf="default->windows+debug" />
Then at least I know that at the dependent module level, I'm able to
restrict the dependency. But then at the publishing module level, I'm really
trusting the dependent module to request "windows+debug" and not just
"windows" or "debug" if I want art1dll.dll to be delivered only in the
windows+debug combination.
Here's the answer to your question: "I don't see any benefit to this as it
seems to be the same as just another configuration name. Maybe if you
elaborated on why you need this?"
Actually, the problem is that it is just another configuration name. Suppose
my Ivy module has 4x4x2=32 JAR artifacts to publish. The JARs are:
- mocha-short-hot
- mocha-tall-hot
- mocha-grande-hot
- mocha-venti-hot
- mocha-short-iced
- mocha-tall-iced
- mocha-grande-iced
- mocha-venti-iced
- latte-short-hot
- latte-tall-hot
- latte-grande-hot
- latte-venti-hot
- latte-short-iced
- latte-tall-iced
- latte-grande-iced
- latte-venti-iced
- cappuccino-short-hot
- cappuccino-tall-hot
- cappuccino-grande-hot
- cappuccino-venti-hot
- cappuccino-short-iced
- cappuccino-tall-iced
- cappuccino-grande-iced
- cappuccino-venti-iced
- americano-short-hot
- americano-tall-hot
- americano-grande-hot
- americano-venti-hot
- americano-short-iced
- americano-tall-iced
- americano-grande-iced
- americano-venti-iced
I would hate to have to create 32 different Ivy confs when I could get away
with just 4+4+2=10:
- mocha
- latte
- cappuccino
- americano
- short
- tall
- grande
- venti
- hot
- iced
Regards,
Garima.
On Mon, Jul 27, 2009 at 3:02 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> configuration groups and intersections are complimentary. intersections
> gives you the ability to have the following scenario:
>
> module A contains artifacts that support both (windows and linux) platforms
> AND (debug and release) types:
>
> art1.dll, conf="windows,release"
> art1d.dll, conf="windows,debug"
> art1.so, conf="linux,release"
> art1d.so, conf="linux,debug"
>
>
> Then if module B is dependent on module A, B can specify a certain platform
> and a certain release type with an intersection:
>
> A->B (windows) delivers both art1.dll and art1d.dll
> A->B (linux) delivers both art1.so and art1d.so
> A->B (windows+debug) delivers only art1d.dll since it is the only
> artifact that exists in BOTH the windows configuration and the debug
> configuration
> A->B (windows+release) delivers only art1.dll since it is the only
> artifact that exists in BOTH the windows configuration and the release
> configuration
> A->B (linux+debug) delivers only art1d.so since it is the only artifact
> that exists in BOTH the linux configuration and the debug configuration
> A->B (linux+release) delivers only art1d.so since it is the only artifact
> that exists in BOTH the linux configuration and the release configuration
>
>
>
> What you seem to want to do is to specify that an artifact is only valid
> within an intersection. So I think you are wanting to use the "+" notation
> in the artifact section of the ivy.xml instead of the dependencies section
> like I requested. Something like:
>
> art1.dll, conf="windows+release"
> art1d.dll, conf="windows+debug"
> art1.so, conf="linux+release"
> art1d.so, conf="linux+debug"
>
>
> I don't see any benefit to this as it seems to be the same as just another
> configuration name. Maybe if you elaborated on why you need this?
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 4:47 PM
> To: ivy-user@ant.apache.org
> Subject: Re: multiple artifact confs: wanting AND instead of OR
>
> Shawn, thanks. I think you're on the right track here. Let me make sure I'm
> not confused in my understanding: configuration intersections (JIRA
> IVY-1093) are NOT to be confused with configuration groups (JIRA IVY-1097).
>
> Actually, it sounds like configuration intersections may be precisely what
> I'm looking for. Can you provide an example of its usage? I'm guessing you
> might have something like:
> <dependency ... conf="default->dachshund+persian" />
>
> I'll take your word that this has been implemented in 2.1.0-rc2, even
> though
> the JIRA issue hasn't been resolved yet.
>
> I had taken a look at configuration groups and it didn't seem like that
> would help. To use the example on
> https://issues.apache.org/jira/browse/IVY-1097, take the following
> publication artifact:
> <artifact name="art51A" type="jar"
> conf="A,*[axis=platform]"/>
>
> I'm supposing that, if only the A conf was requested when that module was
> specified as a dependency, art51A.jar would be delivered. And if only a
> platform conf like windows was requested in the dependency, art51A.jar
> would
> still be delivered. So it would be the EITHER/OR behavior when really I
> want
> the BOTH/AND behavior. Am I interpreting that correctly?
>
>
> On Mon, Jul 27, 2009 at 2:07 PM, Shawn Castrianni <
> Shawn.Castrianni@halliburton.com> wrote:
>
> > There might be a way to use the new "configuration intersection" feature
> I
> > requested several months ago. It is available in the latest IVY
> 2.1.0-rc2
> > release. It wasn't designed to do exactly what you requested, but might
> be
> > helpful. See the IVY website under release notes which reference
> IVY-1093<
> > https://issues.apache.org/jira/browse/IVY-1093> and IVY-1097<
> > https://issues.apache.org/jira/browse/IVY-1097>.
> >
> >
> >
> > ---
> >
> > Shawn Castrianni
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Garima Bathla [mailto:garima.bathla@gmail.com]
> > Sent: Monday, July 27, 2009 3:20 PM
> > To: ivy-user@ant.apache.org
> > Subject: multiple artifact confs: wanting AND instead of OR
> >
> >
> >
> > Suppose my Ivy module descriptor (ivy.xml) has an
> >
> > /ivy-module/publications/artifact element like so:
> >
> >
> >
> > <artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
> >
> > "dachshund,persian"* />
> >
> >
> >
> > Now, what this means is that cute-dog-and-cat.jar will be grabbed if
> EITHER
> >
> > the dachshund conf or the persian conf is requested. What I would have
> > liked
> >
> > it to mean instead is that the JAR will be grabbed only if BOTH the
> >
> > dachshund conf and persian conf are requested.
> >
> >
> >
> > So I wonder if there's some way for an artifact to be resolved only if an
> >
> > entire combination of two or more Ivy confs is requested. This way I
> could
> >
> > express my dependency on this module with dachshund,persian rather than
> >
> > having to create a bogus combo Ivy conf, dachshund-persian.
> >
> >
> >
> > If I had to describe the generalization of my situation, I would say it's
> >
> > where the Ivy module has a preponderance of artifacts, each of which is
> >
> > needed in a Cartesian product situation, and I want to be able to use a
> >
> > Cartesian product of Ivy confs rather than have to create special
> > "Cartesian
> >
> > product Ivy confs."
> >
> >
> >
> >
> >
> > 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.
> >
>
RE: multiple artifact confs: wanting AND instead of OR
Posted by Shawn Castrianni <Sh...@halliburton.com>.
configuration groups and intersections are complimentary. intersections gives you the ability to have the following scenario:
module A contains artifacts that support both (windows and linux) platforms AND (debug and release) types:
art1.dll, conf="windows,release"
art1d.dll, conf="windows,debug"
art1.so, conf="linux,release"
art1d.so, conf="linux,debug"
Then if module B is dependent on module A, B can specify a certain platform and a certain release type with an intersection:
A->B (windows) delivers both art1.dll and art1d.dll
A->B (linux) delivers both art1.so and art1d.so
A->B (windows+debug) delivers only art1d.dll since it is the only artifact that exists in BOTH the windows configuration and the debug configuration
A->B (windows+release) delivers only art1.dll since it is the only artifact that exists in BOTH the windows configuration and the release configuration
A->B (linux+debug) delivers only art1d.so since it is the only artifact that exists in BOTH the linux configuration and the debug configuration
A->B (linux+release) delivers only art1d.so since it is the only artifact that exists in BOTH the linux configuration and the release configuration
What you seem to want to do is to specify that an artifact is only valid within an intersection. So I think you are wanting to use the "+" notation in the artifact section of the ivy.xml instead of the dependencies section like I requested. Something like:
art1.dll, conf="windows+release"
art1d.dll, conf="windows+debug"
art1.so, conf="linux+release"
art1d.so, conf="linux+debug"
I don't see any benefit to this as it seems to be the same as just another configuration name. Maybe if you elaborated on why you need this?
---
Shawn Castrianni
-----Original Message-----
From: Garima Bathla [mailto:garima.bathla@gmail.com]
Sent: Monday, July 27, 2009 4:47 PM
To: ivy-user@ant.apache.org
Subject: Re: multiple artifact confs: wanting AND instead of OR
Shawn, thanks. I think you're on the right track here. Let me make sure I'm
not confused in my understanding: configuration intersections (JIRA
IVY-1093) are NOT to be confused with configuration groups (JIRA IVY-1097).
Actually, it sounds like configuration intersections may be precisely what
I'm looking for. Can you provide an example of its usage? I'm guessing you
might have something like:
<dependency ... conf="default->dachshund+persian" />
I'll take your word that this has been implemented in 2.1.0-rc2, even though
the JIRA issue hasn't been resolved yet.
I had taken a look at configuration groups and it didn't seem like that
would help. To use the example on
https://issues.apache.org/jira/browse/IVY-1097, take the following
publication artifact:
<artifact name="art51A" type="jar"
conf="A,*[axis=platform]"/>
I'm supposing that, if only the A conf was requested when that module was
specified as a dependency, art51A.jar would be delivered. And if only a
platform conf like windows was requested in the dependency, art51A.jar would
still be delivered. So it would be the EITHER/OR behavior when really I want
the BOTH/AND behavior. Am I interpreting that correctly?
On Mon, Jul 27, 2009 at 2:07 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> There might be a way to use the new "configuration intersection" feature I
> requested several months ago. It is available in the latest IVY 2.1.0-rc2
> release. It wasn't designed to do exactly what you requested, but might be
> helpful. See the IVY website under release notes which reference IVY-1093<
> https://issues.apache.org/jira/browse/IVY-1093> and IVY-1097<
> https://issues.apache.org/jira/browse/IVY-1097>.
>
>
>
> ---
>
> Shawn Castrianni
>
>
>
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 3:20 PM
> To: ivy-user@ant.apache.org
> Subject: multiple artifact confs: wanting AND instead of OR
>
>
>
> Suppose my Ivy module descriptor (ivy.xml) has an
>
> /ivy-module/publications/artifact element like so:
>
>
>
> <artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
>
> "dachshund,persian"* />
>
>
>
> Now, what this means is that cute-dog-and-cat.jar will be grabbed if EITHER
>
> the dachshund conf or the persian conf is requested. What I would have
> liked
>
> it to mean instead is that the JAR will be grabbed only if BOTH the
>
> dachshund conf and persian conf are requested.
>
>
>
> So I wonder if there's some way for an artifact to be resolved only if an
>
> entire combination of two or more Ivy confs is requested. This way I could
>
> express my dependency on this module with dachshund,persian rather than
>
> having to create a bogus combo Ivy conf, dachshund-persian.
>
>
>
> If I had to describe the generalization of my situation, I would say it's
>
> where the Ivy module has a preponderance of artifacts, each of which is
>
> needed in a Cartesian product situation, and I want to be able to use a
>
> Cartesian product of Ivy confs rather than have to create special
> "Cartesian
>
> product Ivy confs."
>
>
>
>
>
> 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.
>
Re: multiple artifact confs: wanting AND instead of OR
Posted by Garima Bathla <ga...@gmail.com>.
Shawn, thanks. I think you're on the right track here. Let me make sure I'm
not confused in my understanding: configuration intersections (JIRA
IVY-1093) are NOT to be confused with configuration groups (JIRA IVY-1097).
Actually, it sounds like configuration intersections may be precisely what
I'm looking for. Can you provide an example of its usage? I'm guessing you
might have something like:
<dependency ... conf="default->dachshund+persian" />
I'll take your word that this has been implemented in 2.1.0-rc2, even though
the JIRA issue hasn't been resolved yet.
I had taken a look at configuration groups and it didn't seem like that
would help. To use the example on
https://issues.apache.org/jira/browse/IVY-1097, take the following
publication artifact:
<artifact name="art51A" type="jar"
conf="A,*[axis=platform]"/>
I'm supposing that, if only the A conf was requested when that module was
specified as a dependency, art51A.jar would be delivered. And if only a
platform conf like windows was requested in the dependency, art51A.jar would
still be delivered. So it would be the EITHER/OR behavior when really I want
the BOTH/AND behavior. Am I interpreting that correctly?
On Mon, Jul 27, 2009 at 2:07 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> There might be a way to use the new "configuration intersection" feature I
> requested several months ago. It is available in the latest IVY 2.1.0-rc2
> release. It wasn't designed to do exactly what you requested, but might be
> helpful. See the IVY website under release notes which reference IVY-1093<
> https://issues.apache.org/jira/browse/IVY-1093> and IVY-1097<
> https://issues.apache.org/jira/browse/IVY-1097>.
>
>
>
> ---
>
> Shawn Castrianni
>
>
>
>
>
> -----Original Message-----
> From: Garima Bathla [mailto:garima.bathla@gmail.com]
> Sent: Monday, July 27, 2009 3:20 PM
> To: ivy-user@ant.apache.org
> Subject: multiple artifact confs: wanting AND instead of OR
>
>
>
> Suppose my Ivy module descriptor (ivy.xml) has an
>
> /ivy-module/publications/artifact element like so:
>
>
>
> <artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
>
> "dachshund,persian"* />
>
>
>
> Now, what this means is that cute-dog-and-cat.jar will be grabbed if EITHER
>
> the dachshund conf or the persian conf is requested. What I would have
> liked
>
> it to mean instead is that the JAR will be grabbed only if BOTH the
>
> dachshund conf and persian conf are requested.
>
>
>
> So I wonder if there's some way for an artifact to be resolved only if an
>
> entire combination of two or more Ivy confs is requested. This way I could
>
> express my dependency on this module with dachshund,persian rather than
>
> having to create a bogus combo Ivy conf, dachshund-persian.
>
>
>
> If I had to describe the generalization of my situation, I would say it's
>
> where the Ivy module has a preponderance of artifacts, each of which is
>
> needed in a Cartesian product situation, and I want to be able to use a
>
> Cartesian product of Ivy confs rather than have to create special
> "Cartesian
>
> product Ivy confs."
>
>
>
>
>
> 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.
>
RE: multiple artifact confs: wanting AND instead of OR
Posted by Shawn Castrianni <Sh...@halliburton.com>.
There might be a way to use the new "configuration intersection" feature I requested several months ago. It is available in the latest IVY 2.1.0-rc2 release. It wasn't designed to do exactly what you requested, but might be helpful. See the IVY website under release notes which reference IVY-1093<https://issues.apache.org/jira/browse/IVY-1093> and IVY-1097<https://issues.apache.org/jira/browse/IVY-1097>.
---
Shawn Castrianni
-----Original Message-----
From: Garima Bathla [mailto:garima.bathla@gmail.com]
Sent: Monday, July 27, 2009 3:20 PM
To: ivy-user@ant.apache.org
Subject: multiple artifact confs: wanting AND instead of OR
Suppose my Ivy module descriptor (ivy.xml) has an
/ivy-module/publications/artifact element like so:
<artifact name=*"cute-dog-and-cat"* type=*"jar"* conf=*
"dachshund,persian"* />
Now, what this means is that cute-dog-and-cat.jar will be grabbed if EITHER
the dachshund conf or the persian conf is requested. What I would have liked
it to mean instead is that the JAR will be grabbed only if BOTH the
dachshund conf and persian conf are requested.
So I wonder if there's some way for an artifact to be resolved only if an
entire combination of two or more Ivy confs is requested. This way I could
express my dependency on this module with dachshund,persian rather than
having to create a bogus combo Ivy conf, dachshund-persian.
If I had to describe the generalization of my situation, I would say it's
where the Ivy module has a preponderance of artifacts, each of which is
needed in a Cartesian product situation, and I want to be able to use a
Cartesian product of Ivy confs rather than have to create special "Cartesian
product Ivy confs."
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.