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.
