Forgive me for nitpicking terminology, but JIRA usage aside, this is not so much a bug to be fixed as a feature request. And I would argue against this feature request for the same reason I'd argued almost exactly a year ago against making "platform" a first-class citizen in the Ivy module descriptor schema. Here's what I had written earlier on this list:
"Right now, the ivy.xml XML schema provides a powerful, expressive general-purpose language for describing transitive dependencies and artifact retrieval. You can use it for pulling JARs into a classpath or for distributing operating system-specific files or delivering apples and oranges for all it cares. It is, and should be, agnostic of its various use cases, many of which we probably haven’t even realized yet. The moment we promote an application of the language into becoming a first-class part of the language itself, we corrupt the language. And worse, we open a Pandora’s box for inviting more applications of the language into the language, further corrupting it and blurring the line between where the language ends and its use cases begin." Currently, aside from jar, Ivy is oblivious of artifact types. Once you add "sources" (or is it "source"?) and "javadoc", where do you stop? Do you add scaladoc, groovydoc, binaries? It used to be that IvyDE scanned for source and javadoc artifacts even though those artifacts weren't represented in the ivy.xml. IvyDE was going beyond the contract of Ivy, like Ivy+DE; it was doing something automagical. Like, "Where did those artifacts come from?" Wisely, I believe, that feature was removed. OK, maybe that's not an apt reference. Correct me if I'm missing something, but it seems that the only use case for giving transitive source and javadoc dependencies special treatment is where they're being resolved from Maven repositories. Otherwise, if it's an Ivy repo and if those artifacts are there, they'll be represented in their associated module descriptor. Well, if you're using Maven repositories, you're already conceding a certain amount of fidelity loss by relying on Maven's more primitive dependency management mechanism. I would say that the failure to pick up source artifacts is just another trade-off you should be willing to make if you decide to live with the Maven "impedance mismatch" and eschew installing your Maven dependencies to an Ivy repo. As a dedicated dependency manager, Ivy is already inherently complicated. It has to be; the problem is not simple. I'd hate to see Ivy's contract grow even more complicated for the sake of workarounds for specific applications when you wouldn't even be needing those workarounds if you were using Ivy in a way that more fully embraced Ivy to begin with. But hey, perhaps there's some other way to address this perceived problem besides polluting the ivy.xml contract. On Tue, Aug 3, 2010 at 2:52 PM, Stephen Haberman <[email protected]>wrote: > Hi, > > I would really like to see this bug resolved: > > https://issues.apache.org/jira/browse/IVY-1003 > > Following up on this thread: > > > http://ant.1045680.n5.nabble.com/pom2ivy-and-transitive-source-retrieving-td1375488.html#a1375488 > > Xavier mentioned this easiest solution: > > Another suggested solution is to add a sources->sources(*) in the > dependency conf mapping, but I see 2 problems with that: > - it makes the sources conf always transitive > - the fallback of * doesn't really make sense > > So what I find would be better is to define a transitive-sources > conf, and have a conf mapping of > transitive-sources->transitive-sources (*), or even better > transitive-sources->transitive-sources(none) if we define 'none' as > a special fallback conf which means no dependency conf if the > required one does not exist. Of course we would need to do that for > javadoc too. > > Just to pipe in 1 year later: > > * "it makes the sources conf always transitive" > > -- Exactly, given transitiveness is the whole reason people are using > something like Ivy/Maven in the first place, I don't think anyone who > has already explicitly pulled in "sources" is going to be upset about > getting all of the sources vs. the non-transitive ones. If you want > sources, you generally want them all. > > For example, is there a non- transitive "default" conf? Why should > sources be special-cased non-transitive? > > * "the fallback of `*` doesn't really make sense" > > -- True, but when is `sources` not going to exist in upstream ivy xmls? > If you want A from a Maven repo, Ivy makes an A.xml, any dependencies of > A are surely going to come from Maven repos as well (else A's pom would > be broken), which means ivy will again be making a B.xml/C.xml for each > upstream Maven B.pom/C.pom, and each of those, being ivy-produced, will > always have a sources conf. > > I'm having trouble imagining a scenario where a Maven-derived project > ends up depending on an upstream non-Maven-derived project that would > not (or could not easily have) a sources conf. > > Given that the `none` fallback feature still hasn't appeared, I'd like > to request that `sources->sources(*)` is called good enough and put in. > > - Stephen > >
