ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Sinclair <>
Subject Re: Solution to native dependencies with Ivy
Date Sun, 02 Aug 2009 22:20:28 GMT
Thanks Shawn and Mitch for your responses.

It seems as if we are in agreement that the type attribute should
identify that the artifact is a native library. In Shawn's case he has
opted for type="bin". What there is debate over at the moment is how to
declare artifacts being available for different platforms and how to go
about resolving them.

On the declaration side, I don't agree with Mitch that platform
information is an application of the language. The fact is that a native
artifact has some additional information that needs to be described in
the module descriptor. An end user should be able to look at an ivy file
and see what platforms an artifact is available for. This information
must also be available in order to segregate artifacts with the same
name and extension for the situation where you are building an
application on several platforms using a shared cache location (e.g.

Shawn has opted to use configurations to identify which platforms an
artifact is available for whereas I've opted to use an additional
attribute. The main reason why I chose an extra attribute was because I
can easily use this as my type token in a file system resolver. I do
agree with Mitch that adding an extra attribute is probably not the
right way to go but also don't completely like using configurations in
the way we have them at the moment. Perhaps configurations are fine or
in the future we will have conf-like attributes or functions on confs
which will solve this general use-case.

>>From my perspective what I really want is a solution that will allow
IvyDE to integrate with the java.library.path in Eclipse since this
appears to be a major gap in the IDE integration. The ultimate solution
of how we structure/resolve native libraries is likely to be constrained
to the ivy-settings.xml file or in the end user's ivy.xml module
descriptor. Hence it seems to me that in order to provide IvyDE
integration, it would be sufficient enough to have a native library type
filter in the preferences (just like we already have for javadocs and
source). This would work regardless of the solution we come up with for
how we structure the Ivy file. 

Would everyone be happy having this added as a feature to IvyDE or see
any problems with this?


On Sun, 2009-08-02 at 10:32 -0700, 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
> >
> >

View raw message