Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4BA1C192.60801@holsman.net>
Date: Thu, 18 Mar 2010 17:00:50 +1100
From: Ian Holsman <lists@holsman.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: dev@cassandra.apache.org
Subject: Re: Binary release artifacts (or What a User Wants)
References: <1268860877.20989.137.camel@erebus.lan>
In-Reply-To: <1268860877.20989.137.camel@erebus.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/18/10 8:21 AM, 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.
>    

my opinion is to keep ivy.
from what you said it is relatively painless for a customer to get the 
3rd party jars via ivy-retrieve on their build machine.

and I really hope people aren't just grabbing the jar file and deploying 
it in production ;-0

I don't see any negatives, except for the crazy developer who downloads 
the jar and gets on a plane for 5 hours, and kicks himself when he 
realizes he can't code.


> 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?
>
>
> [1]: https://issues.apache.org/jira/browse/CASSANDRA-850
>
>