[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: javahl - why would, or wouldn't I need it?

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-02-04 21:39:31 CET

Steve Cohen <stevecoh1@comcast.net> wrote on 02/03/2005 11:06:54 PM:

> Is it required? If not, what does it do for me?

No it is not required. It is simply the best possible choice currently.
It is much faster than the command line adapter, and it is more
"compatible" with Subversion than replacing it with JavaSVN.

> I've noticed that certain subeclipse oprations (such as compares) are
> agonizingly slow on my otherwise snappy Red Hat 9.0 box. Will javahl
> help with this?

Maybe. One problem with compares in Eclipse is that we cannot just use
svn diff, we have to feed the two revisions to Eclipse and let it do the
compare.

> >>If your package maintainer doesn't ship javahl, PLEASE send them a
> polite email asking them to consider including it.
>
> How would I know if it's included or not? (I am running svn based on
> the RedHat 9.0 RPM packages here.

Easiest way is to open Eclipse preferences to Team -> SVN and see if it
allows you to select the JavaHL adapter.

> >>If worse comes to worse (and this isn't too bad), you can build
> javahl yourself. Consult the SVN install documentation for more info.
> Can you please provide a URL? Which SVN install documentation are you
> referring to?

http://svn.collab.net/repos/svn/trunk/INSTALL

> >>The short course goes like this:
> >>./configure --your-other-flags=here --enable-javahl
> --with-jdk=$JAVA_HOME --with-jikes=$JAVA_HOME/bin/javac &&make &&
> install install-javahl
>
> Against which source code base is this to be run? I see no download
> site for the source code here.

JavaHL is part of Subversion. So, typically you would be using the
tarball for the latest release.

By the way, here are some recent instructions from one of the JavaHL
maintainers on how best to build it:

========== BEGIN QUOTE

"i am the author of the javahl binding. But not the author of the
integration into the main bilding system.
If you want to build the javahl binding on the 1.1.* branch on *nix
system, it is not so complicated anymore.

First run ./configure --enable-javahl [--with-jdk=...] [--with-junit=...]
plus your usual options. The with-jdk option is needed, when JAVA_HOME
does not point to your jdk directory. The with-junit option is need when
you want to run the tests and should point to the junit jar.
Then run
make
make javahl
make install
make install-javahl
[make check-javahl]
That should give you a usable javahl binding."

========== END QUOTE

Note, that you need to build and install Subversion itself in addition to
JavaHL as JavaHL uses the Subversion libraries. The above instructions
take that into account, I just wanted to make it clear that is what is
happening.

The final issue that this does not mention is that on some versions of
Linux, particularly Debian based systems, the location that Subversion
installs these libraries to is not in the LD_LIBRARY_PATH so by default
Java will not find them at runtime when JNI tries to load the libraries.
So if you are having problems after building the libraries, that is
something to check into. There are a number of different ways to
potentially solve the problem, but the best would be to try to set that
variable. I do not know much about *nix so I cannot offer too much more.
When I was playing with it, the best I could get was to have these
variables set when I opened a Terminal session, and I then launched
Eclipse from that session. But that was just my inexperience with *nix.
On a Suse system, I did not have these problems at all, just building was
enough.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Feb 5 07:39:31 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.