ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: Configurations really hard to understand
Date Thu, 16 Aug 2007 06:57:51 GMT
You can put  :

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

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',

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

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


2007/8/15, Matthias Kilian <>:
> On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> > Maybe configuration mapping is too difficult to understand... I agree that
> > 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="${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ómez Garrido in


View raw message