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 <[EMAIL PROTECTED]> > 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
