ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <>
Subject Re: Solution to native dependencies with Ivy
Date Mon, 03 Aug 2009 03:24:24 GMT
For the record, the choice of platform/OS is *not *the domain I was trying
to address with the “feature request” thread I started. You might notice
that the example I used in requesting configuration intersections at
the *artifact
*level was copied verbatim—*right down to the artifact names*—from Shawn’s
example in requesting configuration intersections at the *dependency *level.
It just seemed like the coffee drinks domain I started out with was getting
in the way of people looking at the problem, so I wanted to come up with a
domain that would gain a little more acceptance.

I like Mitch’s outline of a proposal, either the “filters” or the “building
blocks,” provided it addresses the fact that my configuration intersections
problem turned out to be more complex than I had originally imagined. Again,
I hate to go back to the coffee drinks domain that people hated, but I need
to be able to specify a mocha-tall combination where I get:

   - mocha.jar
   - mocha-tall.jar

But I DON’T get:

   - tall.jar

To do this strictly by defining special combo Ivy confs would get out of
hand in no time—because, as stated, this example is an oversimplification.


On Sun, Aug 2, 2009 at 10:32 AM, Mitch Gitman <> wrote:

> Jeffrey:
> I love the way you’ve presented this idea, but this is one idea I would be
> opposed to. The problem is that it confuses Ivy module descriptors with one
> particular application of Ivy module descriptors.
> Right now, the ivy.xml XML schema provides a powerful, expressive
> general-purpose language for describing transitive dependencies and
> artifact
> retrieval. You can use it for pulling JARs into a classpath or for
> distributing operating system-specific files or delivering apples and
> oranges for all it cares. It is, and should be, agnostic of its various use
> cases, many of which we probably haven’t even realized yet. The moment we
> promote an application of the language into becoming a first-class part of
> the language itself, we corrupt the language. And worse, we open a
> Pandora’s
> box for inviting more applications of the language into the language,
> further corrupting it and blurring the line between where the language ends
> and its use cases begin.
> It seems like with platform or operating system we’re trying to create
> something that is not an Ivy conf itself but is an extra dimension or
> parameter or filter that gets applied to Ivy confs. If we make platform
> part
> of Ivy, what happens when we encounter the next particular
> dimension/parameter/filter that we want to apply to Ivy confs? Do we
> promote
> that into the module descriptor language as well? Every time another
> dimension/parameter/filter arises, we have to rekindle the heated debate
> about which one is worthy of the language and which isn’t. I can see myself
> crying foul, “You promoted platform. Why can’t you promote this?”
> And even then, we still don’t have support for arbitrary extra
> dimensions/parameters/filters.
> Instead, I suggest we take a step back and try to come up with a
> general-purpose solution to this problem, one that will solve all the use
> cases that come up, not just the choice of operating system. This is where
> I
> go back to an idea Garima broached in the post requesting configuration
> intersections at the artifact level: “And I think the ideal solution would
> be to acknowledge that Ivy confs, as originally conceived, are not
> composite
> constructs; so we need to introduce composite elements that can be used to
> construct confs.”
> The way that Ivy confs are now designed, any single Ivy conf can and must
> be
> able to stand on its own. What we need are constructs that don’t stand on
> their own. I can think of two potential high-level ways to accomplish this,
> either of which could address both the operating system problem and the one
> that Garima offered:
>   - Something like filters that are not themselves Ivy confs but which can
>   be applied to Ivy confs. I’m familiar with configuration groupings, and
>   they’re not quite the same thing.
>   - Building blocks for Ivy confs. So an actual Ivy conf you might specify
>   on an artifact is not literally defined as a conf. It’s a composite of
> the
>   different building blocks. These building-block elements would coexist
> with
>   the first-class Ivy confs. Really, this isn’t such a radical idea. As an
>   analogy, consider an email address: mgitman and are the
>   particular elements that are put together to form, and
>   even the Internet domain is formed from gmail and the .com
>   top-level domain.
> In fact, even the operating system/platform problem seems a lot more
> multi-dimensional than just a platform attribute allows. I mean, ia32.linux
> implies a combination of ia32 and linux.
> P.S. I’m writing this without having had a chance to digest Shawn’s
> response.
> On Sat, Aug 1, 2009 at 3:14 PM, Jeffrey Sinclair <
> >wrote:
> > ivy-user,
> >
> > The handling of artifacts to populate the java.libary.path has cropped
> > up a couple of times on the mailgroup and there is an outstanding JIRA
> > relating to this [IVY-600].
> >
> > I'm finding that more people are being hit by this, in particular in
> > Eclipse through IvyDE. I've come up with a solution that I feel will
> > work well for both Ivy and IvyDE:
> >
> >
> >
> >
> > As described in the blog entry, I'd like to propose a mixture of using
> > types as well as a new attribute on the artifact named platform.
> >
> > I'd like to put a proof of concept together and hence would be grateful
> > for any feedback on my proposal and evaluation of existing solutions.
> >
> > Regards,
> >
> > Jeff
> >
> >

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