I don't have a problem with the javahl APIs. If they're available, by all
means. It wasn't an issue of jar size or confusion as to the need (or lack
thereof) of the native APIs. I just found the javahl dependency on a javasvn
implementation unexpected.
svnClientAdapter, as I understand it, supports 3 clients explicitly: command
line, javahl, and javasvn. I had assumed that enabling one of those clients
would mean that the dependencies of the other clients wouldn't be required.
I mean, if javasvn is going to use javahl anyway, why bother with an
explicit 'javasvn' client type? Just include the javasvn-javahl.jar file and
let the classloader sort it out.
Anyway, it's not that big a deal. I totally understand why you're not
interested. I would like to know what explicit javasvn client support
provides on top of the standard javahl functionality? Are there features
javasvn has that aren't adequately exposed through javahl, or are there
limitations in javasvn vs the native version that need to be accomodated?
Would it be possible to discover automatically that javasvn was being used
as the javahl implementation and have the factory adjust according to which
implementation it provided?
Thanks for your response, and thanks again for your efforts here.
-Scott
On 8/31/06, Mark Phippard <markp@softlanding.com> wrote:
>
> scott.haug@gmail.com wrote on 08/26/2006 02:22:34 AM:
>
> > For my project ivy+svn, I introduced a "pure" javasvn adapter for
> > svnClientAdapter, to bypass javahl dependencies. Given that javasvn
> ships
> > separate from the javahl libs, I find avoiding that extra dependency, at
>
> > least for my project, was worth the separation. My implementation
> borrows
> > heavily from both SVNClientImpl.java from the javasvn project and
> > AbstractJhlClientAdapter.java from svnClientAdapter. It can be checked
> > out/viewed at the following URL:
> >
> > http://ivy-svn.googlecode.
> > com/svn/trunk/ivy+svn/src/java/org/ivytools/svnclientadapter/javasvn/
> >
> > It isn't heavily tested, but works perfectly well for my project.
> Because of
> > the heavy code duplication, it is just begging for refactoring, but that
>
> > wasn't possible without modifying the svnClientAdapater code base
> directly,
> > which was a path I didn't really want to go down if no one else was
> > interested in this effort.
> >
> > I happily offer this work to svnClientAdapter, if the project is
> interested
> > in a javahl-free implementation of the javasvn adapter. If not, I'll
> just
> > keep it as part of my project.
> >
> > Many thanks for this very useful library!
>
> Why did you consider JavaHL a problem? Were you aware that you only need
> to include the JAR? It is only 43 KB. Given that JavaSVN + Ganymed is
> over 1 MB what was the issue in including that JAR? You did not think you
> needed the native libraries too did you? JavaSVN just provides an
> implementation of the Java interfaces from JavaHL.
>
> There was a time that I would have liked this code, but now I think that
> Alex is pretty committed to supporting the JavaHL interface so I do not
> see any reason to not use his code. There is no real advantage to having
> our own implementation that has to "keep up" with his changes.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
Received on Thu Aug 31 22:08:22 2006