ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <>
Subject Re: sources as conf or type
Date Fri, 30 Oct 2009 02:13:10 GMT
On Thu 2009-10-29 at 18:30h, Stephen Haberman wrote on ivy-user:
> Niklas Matthies-2 wrote:
> > 
> > Yeah, but in the end it's just the same problem backwards, in that it
> > really is an open-ended list. Maybe you actually need
> > excludetype="source,javadoc,pdfmanual,debugsymbols" or whatever.
> > 
> > In any case, it's an interesting discussion, as both approaches have
> > drawbacks, and it isn't perfect either way.
> Let me know if I'm misinterpreting here, but your main point seems
> to be that using same conf with type=jar|source is not ideal because
> type is a free form field and upstream projects could use different
> values. So you'd need a convention.
> Which is true. But isn't that already the same with the conf names?

Yes and no. For one, you can handle different conf name conventions
with conf mappings if necessary. For types on the other hand there's
nothing you can do, you'd be out of luck then. Secondly, confs are not
exclusive like types. Artifacts can belong to multiple confs, and you
can effectively define sub confs (or super confs) of other confs. On
the other hand you can't define sub types or super types. For example
you can't define a type "binary-deliverable" that would include jars,
ears, dlls and whatnot. This means that client modules can't just say
"gimme all binary deliverables", but instead need to know the explicit
list, and for *all* transitive dependencies at that.

If types were hierarchical nodes in a category graph, and a mapping
mechanism would be provided like for confs, then I would agree with
you. Types would be almost like a second type of confs then. Which I
think would be very useful.

> Where I'll get the jetty source but not the jetty-util source
> because they forgot the "sources->sources(*)" mapping.

Luckily there's dual resolvers. ;)
Yes, it's not ideal, but at least you *can* do something about it that

-- Niklas Matthies

View raw message