Return-Path: 
 <ivy-user-return-1460-apmail-incubator-ivy-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-ivy-user-archive@locus.apache.org
Received: (qmail 36020 invoked from network); 16 Aug 2007 06:58:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 16 Aug 2007 06:58:15 -0000
Received: (qmail 28291 invoked by uid 500); 16 Aug 2007 06:58:13 -0000
Delivered-To: apmail-incubator-ivy-user-archive@incubator.apache.org
Received: (qmail 28145 invoked by uid 500); 16 Aug 2007 06:58:13 -0000
Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:ivy-user@incubator.apache.org>
List-Id: <ivy-user.incubator.apache.org>
Reply-To: ivy-user@incubator.apache.org
Delivered-To: mailing list ivy-user@incubator.apache.org
Received: (qmail 28105 invoked by uid 99); 16 Aug 2007 06:58:13 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2007 23:58:13 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 209.85.146.182 as permitted sender)
Received: from [209.85.146.182] (HELO wa-out-1112.google.com) (209.85.146.182)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2007 06:58:12 +0000
Received: by wa-out-1112.google.com with SMTP id n4so527934wag
        for <ivy-user@incubator.apache.org>;
 Wed, 15 Aug 2007 23:57:52 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=CT5KK9D+osGPcS/G5f8R2B6fi49lpRPZAPP35K9he9EorpTbEiTINK5i9fahAAAIBafRpoQHl7uQxOnrf4JFffp/dRYoQo/iarPMG+6/rf3rIkpGIFuORBVTjT+lH1Kbt7cLOnronGRN1ySb+fNSD3e3tONzF9fHw1LB4uty+SQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RQVGVo08i5soDBrtZbGRxYf5g7zI7I6IS6O3aK0TRxqeGhGLEHk3VdS6JdJ/8ulZilH9UBUDEm524IHDVUfJrj7MQr24xkcUJMX34i4MtHnRov7lq/SJeFbBNMTjFWHyuMable3TRV/meZVelA6I57iHup+OVeBEHTlJ9GMT8fE=
Received: by 10.114.146.1 with SMTP id t1mr578835wad.1187247471690;
        Wed, 15 Aug 2007 23:57:51 -0700 (PDT)
Received: by 10.114.103.16 with HTTP; Wed, 15 Aug 2007 23:57:51 -0700 (PDT)
Message-ID: <e9d8a2610708152357o129962bfq30bdfb8843ed74a6@mail.gmail.com>
Date: Thu, 16 Aug 2007 08:57:51 +0200
From: "Gilles Scokart" <gscokart@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Configurations really hard to understand
In-Reply-To: <20070815195127.GA1254@petunia.outback.escape.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <46C342FB.1090208@gmail.com>
	 <43C7278FD7C46E42A193246BC2FEDA5C11B865@PTSCORP-EXCH.pointserve.com>
	 <635a05060708151148g35994371qf0731b6b821e9d4@mail.gmail.com>
	 <20070815195127.GA1254@petunia.outback.escape.de>
X-Virus-Checked: Checked by ClamAV on apache.org

You can put  :

<configurations>
        <include file=3D"${build.script.dir}/configurations.xml"/>
</configurations>

That works well when you want to have some configurations policies.
It works when you want configurations like 'compile', 'runtime',
'test', (like maven, or extended with some others like 'interface',
'assembly').

However, it doesn't work when you want to use configurations for
'feature scope'.  For example, the ivy.xml of the ivy module has
configuration like 'core', 'standalone', 'httpclient', 'oro'.  For
this type of configuration you can not include some standard
configurations.

I'm not sure if you can easily combine both style.

Gilles


2007/8/15, Matthias Kilian <kili@outback.escape.de>:
> On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> > Maybe configuration mapping is too difficult to understand... I agree t=
hat
> > maven 2 scopes are easier to use for average users, at least until you =
reach
> > their limitations (if ever).
>
> Well, I prefer to use my own configurations and arbitraty configuration
> mappings, even if I *could* abuse maven2 scopes. And I'm pretty
> sure that I've already some cases where I really need configuration
> mappings, but I'd to check our Ivy repo to be sure. (I should write
> a short survey of how we're using Ivy anyways, but that'll take
> some time)
>
> > Therefore we should maybe provide a set of
> > configurations and the associated mapping (something similar to maven 2
> > scopes maybe), and still make it possible to use your own conf mapping.=
 In
> > this case users not needing specific things could almost ignore
> > configuration mapping.
> >
> > What do you think?
>
> Would some kind of include mechanism for sets of default conf mappings
> be feasible? Something like
>
>         <dependencies defaultconfmappingset=3D"${some_url_or_file}">
>         ...
>         </dependencies>
>
> ${some_url_or_file} then would define all the conf mappings used.
>
> Since configurations and conf mappings tend to be very policy-driven
> (on a per-organisation or per-projectgroup base), this would give
> maximum flexibility without hard-wiring some automagic stuff into
> Ivy.
>
> Of course, this is just a rough idea; the available configurations
> should be defined in ${some_url_or_file}, too, so the dependencies
> element probably isn't the best place to include it.
>
> Ciao,
>         Kili
>
> --
> Bad English is the international language ;)
>                 -- Gerardo Santana G=F3mez Garrido in misc@openbsd.org
>


--=20
Gilles SCOKART