"Alexander Kitaev" <alex@tmate.org> wrote on 07/20/2005 09:49:50 AM:
> As far as I understood Cedric started with implementaion of
SVNClientAdapter
> for JavaSVN that works with JavaSVN over its own [javasvn] API. As you
wrote
> this job is not yet completed (also JavaSVN API has changed dramatically
> since that time). However, approach JavaSVN is used with Subclipse now
is
> that JavaSVN replaces JavaHL bindings (native library).
>
> I think the easiest (and one that introduces minimum new bugs) way to
> incorporate JavaSVN into Subclipse now would be not to implement one
more
> svnSVNClientAdapter from scratch, but either duplicate existing
jhlAdapter
> or allow its parametrization with SVNClientFactory callback that may
return
> native SVNClient or one from JavaSVN. I was going to do that myself one
day
> :) but if there are any person who have time (no more than a week I
suppose)
> to do this - I will be glad to help.
I think the point was to avoid the namespace clash. We do not want to
ship a version of Subclipse that does not include JavaHL. Unless we
completely redesigned clientAdapter so that each adapter was its own
plugin, there would be classloader problems in getting the right JavaHL
implementation.
Ideally we want to include JavaSVN (minus your implementation of JavaHL)
so that both adapters could be used.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Jul 20 23:50:07 2005