ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Configurations really hard to understand
Date Thu, 16 Aug 2007 07:23:18 GMT
On 8/16/07, Gilles Scokart <gscokart@gmail.com> wrote:
>
> You can put  :
>
> <configurations>
>         <include file="${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.


The configurations definition file inclusion works as a simple inclusion, so
you can define other configurations in the file in which you call the
include. To combine the configurations, you can use the extends feature, but
that's pretty much all. We have no way to allow other combinations like
intersections for instance. But this would go in a direction of adding
features and complexity, and the initial request was quite the opposite :-)

To simplify for those who prefer to avoid thinking about configurations
themselves, we could maybe include the configuration definitions and default
mapping we use for maven 2 poms as a file in the Ivy classpath, and make its
url available as a variable. Then you could use these configurations and
default mapping with something like:
<configurations>
       <include file="${ivy.m2.configurations}"/>
</configurations>

This is pretty easy to do, would it be useful?

Xavier

> 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
> 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 misc@openbsd.org
> >
>
>
> --
> Gilles SCOKART
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message