On Aug 8, 2009, at 1:39 PM, Paul Davis wrote:
But argument by assertion is neither helpful, meaningful, or polite.
Curt is doing us a huge favour for us by spotting these problems,
explaining
some of the possible solutions, and dedicating his personal time to
evaluating
their suitability for the project.
Maybe its just me but I haven't the slightest what problem this thread
is trying to solve. Why would we even think about removing our runtime
dependencies from SVN? I know someone suggested it in thread this
conversation forked from but I never read discussion about why this
would be good or necessary.
The ASF develops and distributes code licensed under the ASL. An ASF
project can depend on software written on other licenses, but
distributing or developing software under different licenses is
somewhere between atypical and prohibited. I think any exception
would have to be granted by the board.
One possibly resolution to the current situation is to remove the code
from the distribution and from the source and have the user obtain the
dependencies from an outside repository in a similar manner to the
method that libmozjs which had once been in the source in a branched
version but is now obtained through the a package manager.
On Aug 6, 2009, at 9:44 AM, Jan Lehnardt wrote:
FWIW, in my two years with Erlang, I've never came across CEAN in
any practical setting. I know it exists, but for all I know, nobody
uses it. There are also the Faxien and Sinian[sp?] distribution
tools, but they are not widespread either. For all I know, the
Erlang community is longing for a release management system.
At that point, I suggested that the Maven Central Repository, while
best known for providing Java dependencies to Maven, is not limited to
providing Java byte code or only to supporting Maven. The central
repo is not part of the ASF, distributes code under a variety of
licenses, has an established organization, procedures, mirror network,
etc. If one were to develop a release management system for Erlang,
using Maven Central to provide the back end leverages prior work and
existing infrastructure. For CouchDB's immediate needs, all that
might be necessary is to get mochiweb, ibrowse and erlang_oauth into
Maven Central and then provide a means for the end-user to pull the
releases from the Maven repo with minimal effort.
I did try to make a distinction between Maven the tool and the Maven
Central Repository. The easiest way to make sure that your project
description is accurate is to build using Maven, however it is
possible to write a POM for artifacts that were prepared by other means.
