On 30.4.2010 11:58, Patrick ALLAERT wrote:
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 ?
here
it will change in future and there will be only one lib, sorry for confusion
opengrok.jar<- here ?
source.war<- here ?
and here too, since this will be unpacked in your webapp container dir,
so find a lib dir which has the rest of the libs (e.g. like lucene jars,
bcel jars, etc.)
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.
well, we built OpenGrok script to support debian ;) (and the header says so)
also there are normal ctags and exuberant ctags, e.g. on Solaris ctags
are just ctags and exctags are exuberant ctags so generalize to ctags is
not that portable
but nothing stands in the way to improve the OpenGrok script to support
Gentoo too !
I'd like to see OpenGrok being able to have a switch to say that you
want javadb history cache and it will setup the necessary stuff for you
... that would be nice!
xing the fingers
L
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
