Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: domain of garima.bathla@gmail.com
 designates 209.85.212.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=bZOw+9NWu/nvJ1wivSPOUsQ9PaOo+ltygv30UmPG6j1w1Sz81NYU7UKoXeRLhPTfkE
         1GRWWwGCJ02Oz2od1Bk6enSz/CUM9l/IGhZTPXwJLbOs1ZqOwO+QkcZ/jyEqxGcIgAoz
         T85H2cEUyvShaqOh2BDN92ds01gOPG+GY3NVM=
MIME-Version: 1.0
In-Reply-To: <7916a6a60908021032s35a02e72wbe8d5d2eb9d2c5a4@mail.gmail.com>
References: <1249164876.6025.12.camel@Lini>
	 <7916a6a60908021032s35a02e72wbe8d5d2eb9d2c5a4@mail.gmail.com>
Date: Sun, 2 Aug 2009 20:24:24 -0700
Message-ID: <1fb30820908022024v7818c0adpecb405aa42c9840e@mail.gmail.com>
Subject: Re: Solution to native dependencies with Ivy
From: Garima Bathla <garima.bathla@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=0016e6464e247b78b90470344e86

--0016e6464e247b78b90470344e86
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

For the record, the choice of platform/OS is *not *the domain I was trying
to address with the =93feature request=94 thread I started. You might notic=
e
that the example I used in requesting configuration intersections at
the *artifact
*level was copied verbatim=97*right down to the artifact names*=97from Shaw=
n=92s
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=92s outline of a proposal, either the =93filters=94 or the =93=
building
blocks,=94 provided it addresses the fact that my configuration intersectio=
ns
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=92T get:

   - tall.jar

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

Regards,
Garima.

On Sun, Aug 2, 2009 at 10:32 AM, Mitch Gitman <mgitman@gmail.com> wrote:

> Jeffrey:
> I love the way you=92ve presented this idea, but this is one idea I would=
 be
> opposed to. The problem is that it confuses Ivy module descriptors with o=
ne
> 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 u=
se
> cases, many of which we probably haven=92t even realized yet. The moment =
we
> promote an application of the language into becoming a first-class part o=
f
> the language itself, we corrupt the language. And worse, we open a
> Pandora=92s
> box for inviting more applications of the language into the language,
> further corrupting it and blurring the line between where the language en=
ds
> and its use cases begin.
>
> It seems like with platform or operating system we=92re 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=92t. I can see my=
self
> crying foul, =93You promoted platform. Why can=92t you promote this?=94
>
> And even then, we still don=92t 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 wher=
e
> I
> go back to an idea Garima broached in the post requesting configuration
> intersections at the artifact level: =93And I think the ideal solution wo=
uld
> be to acknowledge that Ivy confs, as originally conceived, are not
> composite
> constructs; so we need to introduce composite elements that can be used t=
o
> construct confs.=94
>
> 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=92t stand =
on
> their own. I can think of two potential high-level ways to accomplish thi=
s,
> either of which could address both the operating system problem and the o=
ne
> that Garima offered:
>
>   - Something like filters that are not themselves Ivy confs but which ca=
n
>   be applied to Ivy confs. I=92m familiar with configuration groupings, a=
nd
>   they=92re not quite the same thing.
>   - Building blocks for Ivy confs. So an actual Ivy conf you might specif=
y
>   on an artifact is not literally defined as a conf. It=92s a composite o=
f
> the
>   different building blocks. These building-block elements would coexist
> with
>   the first-class Ivy confs. Really, this isn=92t such a radical idea. As=
 an
>   analogy, consider an email address: mgitman and gmail.com are the
>   particular elements that are put together to form mgitman@gmail.com, an=
d
>   even the gmail.com 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.lin=
ux
> implies a combination of ia32 and linux.
>
> P.S. I=92m writing this without having had a chance to digest Shawn=92s
> response.
>
> On Sat, Aug 1, 2009 at 3:14 PM, Jeffrey Sinclair <jeff@cooljeff.co.uk
> >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:
> >
> >
> >
> http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-ap=
ache-ivy/
> >
> > 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
> >
> >
>

--0016e6464e247b78b90470344e86--