ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: sources as conf or type
Date Sun, 15 Nov 2009 13:01:42 GMT

Le 2 nov. 2009 à 16:54, Mitch Gitman a écrit :

> Question for Nicolas Lalevée. And Nicolas, please forgive me for putting you
> on the spot. (Actually, there's nothing stopping anyone else from taking a
> shot at this.)
> Set aside the whole matter of translating a POM. Nicolas, I know you're an
> advocate of the "source as type" approach in general as opposed to "source
> as conf"--having written in the past:
> "Rather than choosing the configuration to select or not the javadocs and
> the sources, you should use the types. Configurations and types are
> orthogonal concepts, you should try to not mix them."
> What's your best argument as to why they *should be *considered orthogonal
> concepts?

First, as the time I wrote it, I was thinking that this was the only good way of managing
sources. I didn't realized that the pom were managed differently. Since the several discussions
here I understand the other point of view.

Per se, types and configurations are two orthogonal concepts, as types and configurations
are independent. Configurations names are not restricted by the types values, types values
are not restricted by the configurations names. So the debate is how do you interpret them
and how do you use them.

Configurations is "a way to use or construct a module" as the doc says [1] and I think everybody
agrees. In the tutorial [2] you can see that we can declare different use of the module, different
use that can be dependent to each other. So requiring the sources would fit this description,
requiring the sources of a module can be seen as a way to use the module.

Then comes the need to declares sources (note that I don't talk yet about type or configuration
for sources in this paragraph, just some abstract "requirement"). The source requirement is
quite orthogonal to the "uses" illustrated in the tutorial: homemade-impl, cc-impl, api. If
"api" is needed, "sources" is not necessary to use "api". And actually I don't know what it
would really mean to ask for "source" without specifying the requirement for "homemade-impl",
"cc-impl" or "api". This little point make me think that configurations are not per se designed
for this.

So at some point we want to declare that an artifact is "api" and "source". And as a user
of the module we want to declare that we want the "sources" of "homemade-impl". There is two
* "source" as configuration
* "source" as type

If configuration is chosen, you need to:
* declare the configuration "source"
* declare that each source artifact is of the configuration "source" 
* don't forget the transitivity in the dependencies (the current issue with the pom)
And the client needs to specify: conf="homemade-impl + source" (+ is configuration intersection
since Ivy 2.1 [3])

If type is chosen, you need to:
* declare that each source artifact is of the type "source"
And the client needs to specify: conf="homemade-impl" type="source"

So both configuration and type can express sources. And the drawback about requiring type
naming to be well known ("src", "source", "sources" and not others), I think this is the same
with the name of the configurations (and actually more painful as transitivity is managed

Finally I just prefer type because it seems simpler to me. And pragmatically because Ivy didn't
support configuration intersection before 2.1. And IvyDE today find sources thanks to the



PS: sorry for the delay in my reply but I find this topic too interesting to do a short reply

> On Sun, Nov 1, 2009 at 7:14 AM, Stephen Haberman
> <>wrote:
>> Nicolas Lalevée wrote:
>>> Sorry I didn't have time to reply to this interesting discussion.
>>> Actually I already have that discussion around the same issue in pom /
>>> ivy mapping there:
>>> I "just" (shame on me) forgot to actually implement the solution we
>>> agreed on. I'll do soon.
>> Ah, no, shame on me for not finding an existing discussion /and/ bug about
>> this from only a few months ago.
>> Thanks for pointing that thread out--though I'm disappointed Xavier didn't
>> like jars+sources in the same conf. :-)
>> I suppose if its gets the job done, I'll be fine, but the
>> transitive-sources
>> conf seems even uglier than the existing sources conf. Granted, it does
>> gain
>> the requested behavior with backwards compatibility.
>> I wonder if there is an another thing lurking here--e.g. something like
>> "primary" vs. "secondary" artifacts, where the primary artifacts are those
>> you want downloaded with a "*" type pattern, but secondary artifacts need
>> explicitly opted-in to a download, e.g. with a type=source (or whatever
>> their type may be).
>> That being said, I usually prefer minimalist solutions (hence not liking
>> the
>> extra "sources" conf), and adding yet another attribute just for this one
>> use case is not exactly minimalist.
>> But I like the conceptual integrity (to me anyway) of jars+sources being in
>> the same conf that I suppose I'm reaching a little bit to see if it could
>> swing that way.
>> (...ah, well, even if you set foo=secondary on the source artifacts, and
>> put
>> them in the master conf, they wouldn't get downloaded without a type filter
>> for master conf, but then they also wouldn't get downloaded without a type
>> filter for the sources conf. So my attempt at backwards compatibility
>> failed.)
>> Thanks,
>> Stephen
>> --
>> View this message in context:
>> Sent from the ivy-user mailing list archive at

View raw message