cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: Binary release artifacts (or What a User Wants)
Date Thu, 18 Mar 2010 04:24:11 GMT
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.

View raw message