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:mgit...@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.castria...@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.bat...@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.
