ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: multiple artifact confs: wanting AND instead of OR
Date Tue, 28 Jul 2009 16:13:51 GMT
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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message