couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Apache Maven/Maven repo (Re: Dependencies in SVN)
Date Mon, 10 Aug 2009 04:30:19 GMT
On Sun, Aug 9, 2009 at 8:39 PM, Curt Arnold<> wrote:
> 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.

Perhaps an exception has been granted for pcre's inclusion in the
httpd server. It was just the first place I looked, I bet there are
more non-APL licensed codebases in the ASF repo.

A general prohibition from keeping dependencies in svn seems rather
odd. I can understand some wariness about maintaining in-project forks
or patches of upstream projects. Diverging from upstream is a bad idea
from a technical perspective alone.

However, I don't understand what we gain from forcing our users to
download mochiweb etc from external sources as part of the build. I
understand this is common in the Java world with Maven, but I don't
know that it gains us anything for our users.

I'd be comfortable with the remedy of working with our upstream
projects to absorb any patches we have outstanding. In the long run,
once we have all our patches cleaned up, we could look at satisfying
our dependencies using some curl shell scripts to download mochiweb,
ibrowse, etc from a repository.

If there were already a standard Erlang package system this would be
simpler. However I don't think adding Maven as a dependency is
acceptable for a non-Java project.

It seems to me that a commitment to getting custom patches out of our
Erlang dependencies would be good, from a technical perspective. I
can't speak to the legal side, but I find the idea that there's a
significant difference between downloading dependencies during the
build and including them in the repository uncompelling.

Curt, do you think your concerns are the sort of thing that should
hold back a release? I understand they technical argument against
forking, but I don't see that being so important that we can't work on
it over time, in the same open-source way we approach other technical


> 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.

Chris Anderson

View raw message