On Wed, Mar 17, 2010 at 11:24 PM, Paul Querna <p...@querna.org> 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. >
Sorry, forgot to finish with bits about the legal parts. Most (all?) the language about NOTICE and LICESE files is specifically related to the source distribution, not the release artifacts -- as long as anyone else can get the same binary artifacts from the source that was voted on, what is actually contained in the binary artifacts is much less concerning, as long as we do respect the licenses of the things we include. C-dev-world: We build win32 binaries using msvc. We distribute them, even distribute mod_ssl, which has a large dependency on OpenSSL, but AFAIK we don't go around appending the entire OpenSSL License to the httpd's LICENSE or NOTICE files? Maybe httpd is wrong, but rules causing so much pain shouldn't exist unless there really is a legal basis for them, not some half finished recommendation on the Incubator website.
