ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: transitive sources revisited
Date Wed, 04 Aug 2010 03:31:30 GMT
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
<stephen@exigencecorp.com>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
>
>

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