ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Solution to native dependencies with Ivy
Date Sun, 02 Aug 2009 17:32:44 GMT
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

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

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