On 8/31/06, Mark Phippard <markp@softlanding.com> wrote:
>
> scott.haug@gmail.com wrote on 08/31/2006 04:08:03 PM:
>
> > 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.
>
> Because JavaHL is really two things:
>
> 1) A set of interfaces that define a high-level API for Subversion
> 2) An implementation that uses JNI to call the native Subversion
> libraries
>
> JavaSVN provides an alternative to #2 written in pure Java. It makes
> sense for us to use that simply because they are providing and maintaining
> it. It does not make sense for us to do our own version.
I understand the difference, and what javasvn provides. I'm not suggesting
(anymore!) you write your own version. I guess I'm asking if the
JhlClientAdapter works with the javasvn implementation of the javahl APIs,
or does it only support the native implementation? If JhlClientAdapter works
with javasvn as the SVNClient implementation, why have an explicit
JavaSvnClientAdapter?
> 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?
>
> I'd say that we already do, do this.
Maybe I'm missing something in the svnclientadapter API, then. As I
understand it, there's a JavaSvnClientAdapter, a JhlClientAdapter, and a
separate factory for each. The adapters both extend the same base class, but
one is not a subclass of the other. So, clearly, there is some distinction
in the functionality they provide, even though the vast bulk of their
implementation is provided by the AbstractJhlClientAdapter base class. My
question, then, is would it make sense to have a single factory that could
detect whether javasvn or the native impl is in use, and return the
appropriate adapter? Is this functionality already in place somewhere and
I'm missing it, or is there a reason I'm not understanding for explicitly
enabling these two clients separately?
Mark
Thanks for helping me understand the svnclientadapter api better. If this
conversation is no longer appropriate for the dev mailing list, let me know
and I'll raise these questions in the appropriate forum.
-Scott
Received on Thu Aug 31 23:54:07 2006