Forgot to mention that on Gentoo, the following command has to be used to start the JavaDB server:
java -Dderby.system.home=$DATA_ROOT/derby -jar /opt/sun-jdk-1.6.0.20/db/lib/derbynet.jar start Patrick 2010/4/30 Patrick ALLAERT <patrickalla...@php.net>: > Thanks for the help, I'm trying to configure it on my Gentoo Linux > system. Will post afterwards some info to get it up and running. > > Until now, sun-jdk has to be installed with the "derby" USE flag to have > javadb. > > What is really confusing is the following point: > > "2) You need to have the derbyclient.jar in lib directory of > opengrok.jar and in source.war WEB-INF/lib > Copy it over from > OpenSolaris: /opt/SUNWjavadb/lib/derbyclient.jar OR > /usr/jdk/instances/jdk1.6.0/db/lib/derbyclient.jar > Debian: /usr/lib/jvm/java-6-sun/db/lib/derbyclient.jar" > > On Gentoo Linux, this file is available at: > /opt/sun-jdk-<version>/db/lib/derbyclient.jar > Where is this file supposed to be copied? > > OpenGrok source directory has the following structure: > > bin/ > doc/ > lib/ <- here ? > lib/ <- here ? > opengrok.jar <- here ? > source.war <- here ? > man/ > > Should this file be copied (symlink ?) inside lib/? lib/lib/ ? or > inside the .jar and .war files (how can this be achieved) ? > > Thanks for your help. > > Patrick > > PS: exuberant ctags were not found. It is quite common to have > /usr/bin/ctags as a symbolic link to "exuberant-ctags" because of this > OpenGrok script has to be hacked a bit. > > 2010/4/30 Lubos Kosco <lubos.ko...@sun.com>: >> >> Hmm, >> incremental history updates were one of goals of having history cache moved >> to javadb (see readme file on how to setup javadb historycache instead of >> default xml.gz files - >> http://src.opensolaris.org/source/xref/opengrok/trunk/README.txt#260 ) >> >> looking at >> http://src.opensolaris.org/source/xref/opengrok/trunk/src/org/opensolaris/opengrok/history/SubversionRepository.java#200 >> it seems opengrok should be doing it - >> http://src.opensolaris.org/source/xref/opengrok/trunk/src/org/opensolaris/opengrok/history/SubversionRepository.java#141 >> >> so I'd give it a whirl with javadb historycache (setup is not that hard, but >> we don't have it out of box yet ... :( ) >> and if it fails there, we shall file bugs ... >> (+ you get the feature of seeing what files were changed by the changeset >> when looking at history cache from javadb - this is not available with >> current xml plain files) >> >> xing the fingers >> L >> >> P.S. if you will be able to add some sensible setup code for javadb done >> (and integrate it into OpenGrok script), the community would be definitely >> interested in a patch (tia!) >> >> On 30.4.2010 9:04, Patrick ALLAERT wrote: >>> >>> Hi list, >>> >>> It appears that while updating, the *entire* "svn log" is taken every >>> time. This is extremely time consuming on very big projects (>1 000 >>> 000 commit like KDE or even PHP with ~300 000). >>> Would it be possible to only fetch what's missing ? >>> The following scenario should be possible: >>> >>> 1. New project added >>> a) Entire svn log fetched. >>> b) Storing last revision seen ( => lastRevisionNumberSeen). >>> 2. Project source being updated (svn update) >>> 3. OpenGrok update: >>> a) If lastRevisionNumberSeen != actual one: svn log --xml -r >>> BASE:lastRevisionNumberSeen >>> b) Storing last revision seen ( => lastRevisionNumberSeen). >>> >>> Altenatively, an "OpenGrok update" could take care of the update of >>> the repository. >>> >>> Thanks for you help. >>> >>> Kind regards, >>> _______________________________________________ opengrok-discuss mailing list opengrok-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
