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: specify versions separate from dependencies
Date Wed, 27 Feb 2008 17:48:56 GMT
On Wed, Feb 27, 2008 at 6:11 PM, Niklas Matthies <ml_ivy-user@nmhq.net>
wrote:

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

I usually agree, if I can envision some kind of use case for the
generalization. In this particular case I don't see what we could override
besides the revision of a transitive dependency.  Do you have any idea?


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

The problem is to parse the included file you need to locate it. and with
Ivy flexible repository settings it's not always easy to know where the
included file is located.


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

That's my point. Using a relative path will make the publication itself
difficult. If we use a module reference, we are getting closer to the parent
mechanism in maven 2. But then, when the file is not published yet, do you
have to publish the included file in the repository? If you don't, how does
Ivy locate it, if it's only a module reference? That's really tricky, and
that's why I'd really prefer not supporting inclusion/parent in the
repository.

Xavier

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



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

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