jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: svn commit: r473755 [1/43] - in /jackrabbit/trunk/contrib/jcr-browser: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/jackrabbit/ src/main/java/org/apache/jackrabbit/browser/ src/main/resour
Date Mon, 13 Nov 2006 00:48:22 GMT
On Nov 12, 2006, at 4:21 PM, Jukka Zitting wrote:
> On 11/13/06, Edgar Poce <edgarpoce@gmail.com> wrote:
>> On 11/12/06, Roy T. Fielding <fielding@gbiv.com> wrote:
>> > Why do we need the dojo library in our subversion?
>> It's not something we need, it's not a hard task to add dojo manually
>> to a webapp. However, I thought that adding javascript libraries to
>> subversion was the common practice, e.g. I think I saw commits of  
>> dojo
>> sources in tapestry and cocoon.
>> Do you think we should remove it?
> No, at least the way I see it. Legally the dependency is fine (though
> having license comments in each file and a standard NOTICE file would
> be nice), so the question is mostly about the technical mechanism used
> to include the Dojo library in the webapp. Since Javascript libraries
> are distributed in source form, there is nothing like a Maven
> repository for them, and pointing a client to download the library
> from somewhere else than the deployed webapp is out of the question,
> the best we can do is to include a copy.

If we are not planning on maintaining the dojo files as a fork,
then we include installation instructions with the webapp, or an
install script that builds a webapp from our source and the latest
tarball from dojo.  The only time that we would distribute both is
when the RM builds a release, at which time the RM would install
the best available version of dojo inside the release jar.

We do not need it in our subversion unless we plan on forking the
dojo content.  We are talking about 20MB of *source*.


View raw message