Pure JavaSVN adapter for svnClientAdapter

scott.hauggmail.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-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

scott.hauggmail.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. 

> 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? 

JavaSVN includes things that native Subversion does not
currently.  It 
kind of does not matter though.  svnClientAdapter is
ultimately based on 
what can be done with JavaHL and mostly just mirrors that
API and 
interface.  There are some places where we have added
options to use a 
custom feature of JavaSVN but there are not a lot of areas
that lend 
themselves to that. 

> 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.

Mark

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

scott.hauggmail.com wrote on 08/31/2006 05:54:00 PM:

> 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? 

No, it doesn't.  Which is not to say that it would have
been impossible to 
have made one that could do both.  If you compare the two
classes, the 
differences are fairly obvious.  The point of creating the
Abstract class 
was to keep the common parts in one place.  That is what
makes sense to 
me.

> 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? 

I fail to see the benefit of that approach.  How could
explicitly pick the 
implementation you wanted if they were both available?  The
current 
approach seems like the proper OO-way to do this.  As an
example, 
Subclipse operates under the assumption that all of the
adapters might be 
available and you can pick the one you want.  If you have
chosen a 
default, we try to load it and have some fallback options if
it fails. But 
if it doesn't fail, startup is faster since only one
adapter is 
initialized.  If you do not have a default chosen we try to
load JavaHL, 
if it is not available we try to load JavaSVN etc..

In our Eclipse proposal, we have changed this to be done
with Eclipse 
extension points.  So the extension point will tell us which
adapters are 
available.

Mark


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org