incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Oskarsson <>
Subject Re: Binary release artifacts (or What a User Wants)
Date Thu, 18 Mar 2010 09:18:33 GMT
Paul Querna wrote:
> On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <> wrote:
>> During the 0.6 cycle Ivy was introduced to manage (most of) our
>> dependencies, and where possible, jars were removed from svn and no
>> longer included in binary release artifacts. Recently though this change
>> has been called into question, with some discussion taking place in
>> CASSANDRA-850[1].
>> The 0.6 release is upon us, but if consensus will be to rollback this
>> change and resume the practice of embedding third-party jars, I strongly
>> feel we should do that now. I don't want to see 0.6 as a one-off that
>> we're forced to explain over and over.
>> We've seen a steadily increasing list of dependencies, but it really
>> exploded between 0.5 and 0.6 (think 2x). This was causing a number of
>> problems:
>> 1. First and foremost, we were doing a less than perfect job of
>> maintaining licensing and attribution. The exact requirements here
>> depend on a number of variables and are fraught with subtleties. Failure
>> to get this right creates legal risks that the ASF finds unacceptable so
>> doing it poorly is really not an option.
>> Ivy "fixed" this problem by side-stepping the issue entirely. If we
>> aren't shipping it, then there is simply no need to maintain this
>> documentation.
>> 2. Many of these dependencies have dependencies in turn (and so on).
>> Sometimes these dependencies (or the dependencies of the dependencies,
>> etc) share dependencies with other dependencies, but with different
>> versions. Sound confusing? It can be, yes, and the complexity seems to
>> grow exponentially to the number of jars we're pulling in.
>> Ivy fixed this problem because this is precisely what Ivy does, it
>> resolves a graph of your project dependencies based on a specification
>> (ivy.xml), and retrieves them.
>> Or to put all of this more simply... tedious, time consuming, and error
>> prone tasks were automated away. This however did not come without a
>> price, and the costs that I see in order of importance are:
>> 1. Downloading arbitrary code off the 'net, (and without a good trust
>> path).
>> 2. Requiring networking connectivity at install time.
>> 3. Requiring ant to be present at install time.
>> 4. One extra step in the install process, (i.e. invoking `ant
>> ivy-retrieve')
>> I know a lot of people wouldn't consider (1) and (2) to be real issues,
>> (just look at how popular Maven is), so YMMV. I personally don't think
>> (3) and (4) are that onerous but I can't disagree with the
>> weird-to-require-a-build-tool argument, or that one more step in Getting
>> Started is still one more step.
>> So to me, this boils down to deciding whether the cure is worse than the
>> disease.
>> Thoughts?
> Lack of java-devness showing: Can't the -bin tarball just include the
> 'ivy-retrieve' step pre-done?
> At least then everyone will test the same -bin, significantly reducing
> the lack of trusted path in problems 1 & 2.

This is what I would also suggest, I don't have anything against using 
ivy to fetch jars for developers. BUT what I think we should do is add 
the jar files downloaded by ivy to the binary distribution to make it as 
easy as possible for users, especially new ones.

I hope that at least one of the two developers (contributor and 
reviewer/committer) involved in any patches that add a new dependency 
would remember to add the correct information to the notice.

We should probably add a section about it here if we decide to go down 
this path:

View raw message