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. > 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. 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. > > - 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. Xavier > > > As above, possibly add an attribute to choose what to do in case of > conflicting/non-mergeable specs. > > Something along these lines would be more generic/orthogonal/flexible > than adding a dedicated construct for the specific use case here. > > -- Niklas Matthies > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
