JAVA高级面试进阶训练营视频教程

admin

首先说要点是：

Subclipse Version	SVN/JavaHL Version
1.10.x	1.8.x
1.8.x	1.7.x
1.6.x	1.6.x
1.4.x	1.5.x
1.2.x	1.4.x
1.0.x	1.4.x

官网说的很清楚，你的svn即subversin/javahl version必须和这张表配对着来，我查了我的svn版本，在终端用svn —version命令即可，是1.8.11所以，必须Subclipse插件是1.10以上的，这里是地址：subclipse 1.10.6.zip地址：http://download.csdn.net/detail/xlshl43/8153519#comment。

我原来subclipse是1.8.多的，我没卸载直接把下载好的1.10.6版本解压，把plugius文件拷贝eclipse中覆盖原文件，打开eclipse不再出现javahl错误。team-svn 客户端接口那里也出现javahl jni 1.8.11.

 

在解决问题前参考文章见附录：

我觉得比较有用的步骤是

 

①打开终端，输入命令：xcode-select —install  这样mac 10.9以后的系统会安装command line tools

②到http://www.macports.org/install.php下载MacPorts包，进行安装，然后命令行执行sudo port -v selfupdate。

③再在命令行输入   sudo port install subversion-javahlbindings +no_bdb +universal等待命令行安装（也有说是这个命令：sudo port install subversion-javahlbindings）。

④如上所说装好subclipse对应版本，终端svn —version查看svn/javahl版本。

 

总结：安装的过程中，有几个名词要注意，subclipse是插件，安装在eclipse中的，svn是subversion的简称，svn的版本即是javahl的版本，这点可以从官方给出的图标推出。

 

下面是附录参考： 

---

 

在Mac 10.8.2系统里， 在Eclipse中安装svn的插件，出现如下提示

 

 

1.根据提示进入链接 http://subclipse.tigris.org/wiki/JavaHL

2. 到 OS X的链接http://subclipse.tigris.org/wiki/JavaHL#head-5bf26515097c3231c1b04dfdb22c036bc511926b

3.根据提示跳转到http://www.macports.org/install.php下载MacPorts包，进行安装

4.安装完毕 在命令行输入  

         sudo port install subversion-javahlbindings +no_bdb +universal

         这一步之前，请安装xcode，和 command_line_tools 。Mac的开发环境必备

注意  ： 如果你们的xCode是用dmg的形式装的，记得拖到application里头     

 

然后等第四部的命令执行完毕就可以在eclipse中使用svn的插件了。

    比在win7和ubuntu下配置要简单的多

 

 MAC OSX Lion安装JavaHL

2013-03-18 14:32 3525人阅读 评论(1) 收藏 举报

问题：

在MAC OSX 10.7下安装了ECLIPSE，再安装subclipse，安装完成后，总是提示找不到JavaHL，根据提示安装了

Subversion 1.6.17 Binaries for Lion (Mac OS X 10.7)

仍然不行，查找网络资料，安装macports，执行sudo port install subversion-javahlbindings的命令，又出现错误Error: Port install not found，可谓步履维艰。不过根据摸索，终于解决了问题，下面按步骤说明，一是便于自己将来查找使用，二是方便其他遇到此类问题的朋友。

 

步骤：

（1）安装subclipse

http://subclipse.tigris.org/update_1.8.x

（2）安装Subversion

http://www.collab.net/downloads/subversion，选择“Community Binaries”；

（3）安装macports

http://www.macports.org/

安装完成macports后，如果执行sudo port install xxx出现Port install not found错误，执行如下命令：

sudo port -v selfupdate

（4）安装javahl

sudo port install subversion-javahlbindings

 

在安装完MacPorts以后，在终端下执行下面的命令sudo port install subversion-javahlbindings，安装javahl 

到这一步的时候出现问题


Error: 
Error: No Xcode installation was found.
Error: Please install Xcode and/or run xcode-select to specify its location.
Error: 
Warning: xcodebuild exists but failed to execute
Warning: Xcode does not appear to be installed; most ports will likely fail to build.
--->  Computing dependencies for subversion-javahlbindingsError: Unable to execute port: can't read "build.cmd": Failed to locate 'make' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it?

 

此问题解决方法：

打开Xcode–》偏好设置–》download–》install command line tools

 

以上步骤完成之后，即可重新启动eclipse，此时subclipse即可使用了。

 

 

JavaHL FAQ

This page will attempt to answer some questions about the Subversion JavaHL library and its role in Subclipse.

Return to Wiki FrontPage

 

内容

1. Get the right version!
2. What is JavaHL?
3. Why does Subclipse need JavaHL?
4. Why doesn't Subclipse provide everything I need to use JavaHL?
5. How do I get JavaHL?
1. Windows 32-bit
2. Windows 64-bit
3. SASL on Windows
4. OS X
5. Linux
1. Troubleshooting
2. Client loads OK on Linux, but locks/crashes Eclipse on first operation
6. Testing JavaHL Library

 

Get the right version!

Before explaining what JavaHL is, it is important that you know what version you need for the version of Subclipse you are using. JavaHL is part of Subversion, so it's version matches that of the Subversion command line client you have installed. Each Subclipse version typically only supports a single Subversion client version (due to API differences). Make sure you get the right version of JavaHL for your Subclipse version.

Current Versions

Subclipse Version	SVN/JavaHL Version
1.10.x	1.8.x
1.8.x	1.7.x
1.6.x	1.6.x
1.4.x	1.5.x
1.2.x	1.4.x
1.0.x	1.4.x

 

What is JavaHL?

JavaHL is a part of the Subversion project. Specifically, it is the Java language binding for the Subversion API. Subversion provides a layered API design that is delivered as native libraries (DLL's). The Subversion command line is simply one consumer of this API. The API is rich in functionality but is also maintained for backwards compatibility. This is the reason there are so many great Subversion clients and tools available, because there is a rich and stable API that provides all of the functionality you need.

Subversion is written in C to provide excellent cross platform support, but also because C produces libraries that are easy to consume from virtually any other language. The Subversion project provides and maintains language bindings for Java, Perl, Python and Ruby. The latter three are provided via the SWIG library and its ability to interface languages with native libraries. JavaHL is a "High Level" API and is provided with custom written C++ code to serve as the JNI bridge between Java code and the native libraries. This design allows us to provide a nice Java API into Subversion.

JavaHL consists of essentially four parts:

1. A relatively thin layer of Java code that provides the API that consumers can talk to from Java.
2. A C++ library (the JavaHL library or libsvnjavahl-1). The Java layer talks to this layer using Java Native Interface (JNI) calls. The C++ layer is where the "High Level" API is implemented. For example, Java may provide a simple API that says "Commit this list of files, using this commit message". The C++ layer takes care of memory management and performing all of the lower level Subversion API calls it takes to complete the request.
3. The Subversion libraries themselves. These are the same libraries that the command line client would install and use. Also, other Subversion clients, such as TortoiseSVN or AnkhSVN would also use these same libraries.
4. Subversion library dependencies. Subversion needs a number of external libraries to operate. The biggest is the Apache Portable Runtime (APR), but it also needs libraries like Neon for the HTTP client and OpenSSL to handle encryption etc.

All four of these layers are needed for JavaHL to work and be used in an application.

 

Why does Subclipse need JavaHL?

Subclipse is written in Java, so it needs to use the JavaHL library to be able to use the Subversion API. Subclipse includes the Java layer of JavaHL. If you look at the previous entry, you see that JavaHL needs three other layers for it to actually work (essentially the native libraries).

 

Why doesn't Subclipse provide everything I need to use JavaHL?

On Windows we do provide everything you need. We cannot do it, for technical reasons, on any other operating system. It has to do with how native libraries are loaded on different operating systems. There is no way to deliver all three of the native layers in a way that the libraries will be found when used from Java and Eclipse. The only way for them to be found is if they are properly installed in the specific locations those operating systems look for libraries. Windows library loading has a quirk we are able to exploit from Java. Basically, we can load the dependencies in reverse order and then as we load each library since its dependencies are already loaded into memory, the loader does not try to load them.

 

How do I get JavaHL?

This will vary by operating system:

 

Windows 32-bit

Subclipse includes everything you need. You just have to be sure to have installed the JavaHL plugin from our Eclipse update site.

 

Windows 64-bit

As of the Subclipse 1.8.x releases, native 64-bit Windows binaries are included with Subclipse so it includes everything you need. For earlier releases of Subclipse follow these instructions:

If you are using a 32-bit JVM, then Subclipse should just work. If you use a 64-bit JVM then you need to provide a 64-bit version of JavaHL. One such distribution is SlikSVN which you can get here:

http://www.sliksvn.com/en/download

With that package installed, Subclipse should find JavaHL on PATH and just work.

 

SASL on Windows

If you are using SASL for authentication with the svn:// protocol you need additional Windows binaries. SASL requires auth plugins to be installed and configured in the registry. Since we use the Windows DLL's that ?CollabNet provides the best way to handle this is to install the Windows command line client that ?CollabNet provides. The installer will install the additional SASL plugins and configure the Windows registry. The JavaHL binaries will automatically make use of these plugins once they are installed. You can download the installer from:

http://www.open.collab.net/downloads/subversion/

 

OS X

OSX comes with a SVN command line client, but unfortunately they do not include the JavaHL library.

The best thing to do is to install one of the OSX package managers for open-source software, such as MacPorts or HomeBrew. If you are doing software development on OSX, you are going to eventually want or need different open-source Unix applications. So it is worth the effort to set one of these up and they make it easy for you to get Subversion and always have the latest version. You will also have easy access to other open source applications via similar simple commands.

For MacPorts, the commands to run are:

 

sudo port install subversion-javahlbindings +no_bdb +universal

For HomeBrew the command is:

 

brew install --universal --java subversion

Pay attention to any post-install instructions related to creating a symlink in /Library/Java/Extensions. You need to follow these instructions so that the JavaHL library is available by default to the JVM.

 

Linux

This is the most complicated because there are so many distributions.

CollabNet provides a client RPM for Red Hat that includes JavaHL (http://www.collab.net/downloads/subversion/redhat.html). In my experience, this RPM works on other Linux distributions. On RPM-based distributions like CentOS or Suse, it should just be a matter of installing the RPM. On Debian-based systems, I was able to use the alien package to install the RPM.

Of course many Linux distributions, such as Ubuntu, do a good job of providing up to date Subversion packages, and most of these now provide JavaHL as well. Typically, the JavaHL library is in a separate package that is dependent on the main Subversion package. In Debian/Ubuntu the package name is libsvn-java so you can just run this command to install the library:

$ apt-get install libsvn-java # Use sudo in Ubuntu

Next, find the path where the JavaHL library is installed, as you will need to know this path for the following instructions:

$ find / -name libsvnjavahl-1.so # Use sudo in Ubuntu

Although the library is installed, you still have to tell Java (when used for Eclipse) where to find it. The JVM on Linux does not look in a lot of the standard locations to find the libraries. (This could obviously change in the future.) For example, 32-bit Debian/Ubuntu uses a standard location of /usr/lib/jni for libraries to be used from Java. However, the Oracle JVM does not currently look in this location. The easiest way to tell Java where to find the JavaHL library is to specify the following when starting the JVM:

-Djava.library.path=

Example:

 

-Djava.library.path=/usr/lib/jni

CollabNet Subversion installs into /opt/CollabNet_Subversion. So if you are using that package, you need this:

 

-Djava.library.path=/opt/CollabNet_Subversion/lib

Eclipse provides its own mechanism for providing this setting. Eclipse comes with a file named eclipse.ini. This file is looked at when the Eclipse launcher starts the JVM and appends settings to the JVM when launching it. Specifically, you should see a line that says "-vmargs". Add a newline after this line and insert the above line to pass the setting the JVM needs. Each argument needs to be on its own line, so be sure to add a new line and then put the entire string above on its own line. Here is an example of this file from Eclipse 3.4:

 

-showsplashorg.eclipse.platform-frameworkplugins/org.eclipse.osgi_3.4.0.v20080605-1900.jar-vmargs-Djava.library.path=/opt/CollabNet_Subversion/lib-Dosgi.requiredJavaVersion=1.5-Xms40m-Xmx512m-XX:MaxPermSize=256m

 

Troubleshooting

You can tell if JavaHL has loaded by looking at the Eclipse preferences under Team < SVN. If the library loaded correctly you will see the version of the library, otherwise it will show "Not available". If a version of the library that is too old to use is found, then we do not load the library and it will show as "Not available".

A common problem that Linux users have run into is that they edit the eclipse.ini file to point to the path where the library is loaded but it still does not work. Something to check if this happens to you is whether the settings in the INI file are being used. A lot of users customize the launcher they create to run Eclipse and they include some command line options for starting Eclipse. When you do this, it appears that the Eclipse launcher does not use any of the settings in the INI file. The easiest way to see this is happening is to do Help < About in Eclipse and then choose Configuration Settings. If you look through the settings you should eventually be able to see the command line settings used for the JVM. If you do not see the java.library.path line then it was not used.

 

Client loads OK on Linux, but locks/crashes Eclipse on first operation

There is currently a bug in the new support for GNOME keyring in Subversion 1.6. It works OK when using the command line, but not when other users of the libraries use it. Until this is fixed, you can workaround the problem by turning off this feature. To do this, open the file ~/.subversion/config and add the following:

 

[auth]### Set password stores used by Subversion. They should be### delimited by spaces or commas. The order of values determines### the order in which password stores are used.### Valid password stores:###   gnome-keyring        (Unix-like systems)###   kwallet              (Unix-like systems)###   keychain             (Mac OS X)###   windows-cryptoapi    (Windows)password-stores = 

The empty value for "password-stores" disables the feature. Passwords will be stored in plain text in the auth folder as with all previous version of Subversion.

 

Testing JavaHL Library

If all of the above has not helped and you are having problems getting the JavaHL library to load or run, it can help to run the Subversion JavaHL JUnit tests on your installation. Typically, this will give the same errors you get in Subclipse, but it can be easier to perform trial and error and diagnose the problem.

To make it easy to run the tests, we have bundled up the Subversion tests, JUnit and the JavaHL classes into a single JAR file. You can download the tests for Subversion 1.6 with the following link:

javahltests.jar

This JAR file will only work with the Subversion 1.6.x version of the JavaHL libraries. To run the tests do the following:

Create a new folder and copy the JAR file into it. Then open a terminal and cd to the folder you created and run:

 

$ java -jar javahltests.jar....................​....................​..........Time: 145.805OK (50 tests)

The tests create a bunch of repositories and working copies, so run these from a folder you can easily delete or cleanup. Also, you will want to be sure you run the tests using the same JVM that you are using for Eclipse. Finally, you will need to make sure the JavaHL library is on your PATH. So you will probably need to run it something like this:

 

$ java -Djava.library.path=/opt/CollabNet_Subversion/lib -jar javahltests.jar....................​....................​..........Time: 145.805OK (50 tests)