Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of paul@querna.org designates
 209.85.160.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1268860877.20989.137.camel@erebus.lan>
References: <1268860877.20989.137.camel@erebus.lan>
Date: Wed, 17 Mar 2010 23:24:11 -0500
Message-ID: <4239a4321003172124p2c194697o6dbbe6b4ae6a66aa@mail.gmail.com>
Subject: Re: Binary release artifacts (or What a User Wants)
From: Paul Querna <paul@querna.org>
To: dev@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <eevans@rackspace.com> 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.
>
> BACKGROUND
>
> 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.