I do not see how this would work. svnClientAdapter has code which
attempts to load the JavaHL libraries, and if it fails, then it disables
the JavaHL adapter. Your solution would only work if svnClientAdapter
could still load the JavaHL libraries.
Second, I do not see where this is a matter of Subclipse needing an
extension point. Subclipse uses svnClientAdapter. It should be possible
to create an adapter for JavaSVN and it would just automatically register
itself with Subclipse and be available. I believe this would also make it
available to svnAnt which would be a side-benefit. By recreating the
JavaHL "namespace" doesn't it just complicate things as it is now not
possible to create the appropriate adapter for JavaSVN and include it in a
distribution that also includes JavaHL.
Since you have done the work to recreate the JavaHL "interface", perhaps
you could just rename the package into your own namespace. Then code
which uses JavaHL, could just rename the import statements and switch to
your implementation? It seems like an adapter for JavaSVN could then be
made fairly easily using this approach and copying the existing JavaHL
adapter.
Thanks
Mark
"Alexander Kitaev" <alex@tmate.org> wrote on 11/23/2004 11:05:05 AM:
> Hello All,
>
> The latest version of JavaSVN library (http://tmate.org/svn/) may be
used as
> a replacement for javahl bindings in subclipse. You may find complete
> instructions at http://tmate.org/svn/subclipse.html
>
> Shortly, to make Subclipse use JavaSVN library one have to replace
> svn-javahl.jar with javasvn.jar and make appropriate changes in
subclipse
> plugin.xml file. This configuration was tested on Windows XP SP2,
Eclipse
> 3.1M3, Subclipse 0.9.22.
>
> I do understand that this is not the best way to integrate javasvn into
> subclipse, and it will be much better to use extension points, but the
> latest stable version of Subclipse (0.9.22) doesn't allow to extend
itself
> with custom svnClienAdapter implementation. In case of javasvn this
> implementation may be the same as javahl one but with different set of
jar
> files and without all the native dlls.
>
> Thanks,
> Alexander Kitaev.
>
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Nov 24 03:29:25 2004