incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Binary release artifacts (or What a User Wants)
Date Wed, 17 Mar 2010 21:21:17 GMT

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?


[1]: https://issues.apache.org/jira/browse/CASSANDRA-850

-- 
Eric Evans
eevans@rackspace.com



Mime
View raw message