ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 17:11:29 GMT
On Wed 2008-02-27 at 17:00h, Xavier Hanin wrote on ivy-user:
> On Wed, Feb 27, 2008 at 4:42 PM, Niklas Matthies <ml_ivy-user@nmhq.net>
> wrote:
> 
> > As for how to implement this in Ivy, how about:
> >
> > - Provide an inclusion facility for ivy files to semantically
> >  include/merge the contents of some other ivy file, similar as
> >  "include" for the settings files. Possibly add an attribute to
> >  choose what to do in case of conflicting/non-mergeable specs.
> 
> Vote for IVY-742! As you can see, Gilles is not in favor of supporting this
> kind of mechanism in Ivy. But Ivy is community driven, so your vote and
> opinion really count.

I added a comment to the issue. Personally I haven't had the need for
something like that in Ivy yet. It's just that I hate seeing features
being added that let you do something (e.g. "override") to just one
particular type of object (e.g. "revision of a transitive dependency"),
and not for all objects where it makes sense. :)

> >  IMO *any* configuration/specification file format ought to have such
> >  a mechanism.
> 
> The problem with this kind of mechanism is that it make things more complex
> to understand, and more complex to parse too.

Well, the merging should happen after the actual parsing (but maybe
that's what you mean).

> IMO, a good compromise would be to disallow inclusion for ivy files
> in the repository. Having selfcontained metadata in the repository
> makes things much easier, especially for external parsing and
> analysis.

The resolved ivy file (as produced by the deliver task) probably
should textually contain the included settings. Apart from that I
wouldn't necessarily bother to disallow inclusion in retrieved ivy
files (similar as for dynamic revisions). The question is probably
more how such an include reference would look like. A relative file
path? A module reference?

> > - Add the possibility to specify any kind of ivy file tags under the
> >  "module" tag of a settings file, to be semantically injected into
> >  the ivy files of all matched modules. Basically a "reverse-include".
> 
> I'm not a big fan of mixing too much of resolution metadata between settings
> and ivy files. I much prefer keeping this kind of things in ivy files. If we
> support some kind of parent mechanism and a dependencyManagement feature, we
> cover the need, and still keep most resolution metadata in Ivy files, and
> thus in the repository.

I guess I agree, except for the specific "dependencyManagement"
feature. See my next post.

-- Niklas Matthies

Mime
View raw message