Paul Querna wrote:
On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <eev...@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.

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: http://wiki.apache.org/cassandra/HowToContribute

Reply via email to