ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: multiple artifact confs: wanting AND instead of OR
Date Tue, 28 Jul 2009 05:36:42 GMT
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:

	<conf name="windows" ext:grouping="platform"/>
	<conf name="linux" ext:grouping="platform"/>
	<conf name="solaris" ext:grouping="platform"/>

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:

	<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"/>

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:

	<dependency name="B" rev="latest.integration" conf="*->@+release"/>

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:

	<dependency name="C" rev="latest.integration" conf="*[grouping=platform]->@;*[grouping=quality]->*"/>

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 [] 
Sent: Monday, July 27, 2009 11:17 PM
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:

Quote: "In this ivy file, *[axis=platform] is equivalent to windows,linux"
So this...:
<artifact name="art51A" type="jar" conf="A,*[axis=platform]" /> equivalent to this:
<artifact name="art51A" type="jar" conf="A,windows,linux" />

In other words, configuration groups/groupings give you union, not

The closest I can come to accomplishing what Garima's requesting is this:
  <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" />

  <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 <> 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:
> 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 []
> Sent: Monday, July 27, 2009 6:05 PM
> To:
> 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.
View raw message