ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Haberman <>
Subject Re: sources as conf or type
Date Sun, 01 Nov 2009 15:14:25 GMT

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


View this message in context:
Sent from the ivy-user mailing list archive at

View raw message