ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 16:00:11 GMT
On Wed, Feb 27, 2008 at 4:42 PM, Niklas Matthies <>

> 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.


>  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

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