RE: Suggestions for JavaSVN/JavaHL integration

Hello Holger,

I'm not sure whether my suggestion is the same as yours, but what I mean is that:

Client will get the following jars and put them on classpath:

- svn-common.jar // contains API and command line client implementation And one of the following (or both:)
- svn-pure.jar
- svn-jni.jar

The code will look like:

SVNJni.setup(); // this class is from svn-jni.jar, may be replaced with Class.forName(...) like with JDBC drivers or set up automatically in environments like Eclipse
SVNPure.setup(); // this class is from svn-pure.jar

ISVNClient client = SVNClientManager.getSVNClient(SVNClient.PURE_JAVA); // or ISVNClient client = SVNClientManager.getDefaultSVNClient();

This way client will get jni or pure java implementation depending on what jars are on classpath.

Also there may be an SVNWrapper implementation of ISVNClient that will select what exact implementation to use for every method. For instance, assuming there are both svn-pure.jar and svn-jni.jar exists, it may delegate calls to JNI implementation for "file://" operations and to pure java implementation for others. And particular implementation may provide information (either with a special method or by throwing a NotImplemented exception) about which operations are supported, so SVNWrapper may "try" to invoke pure java implementation first and then jni implementation if certain method is not implemented in pure java version.

Alexander Kitaev.

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Holger Hoffstaette
> Sent: Thursday, March 03, 2005 4:59 PM
> To: dev@subversion.tigris.org
> Subject: Suggestions for JavaSVN/JavaHL integration
>
>
> With great interest I read about the suggested integration of JavaSVN
> into the main subversion tree and applaud it wholeheartedly. I agree
> with all that's been said so far but would like to add another view on
> reducing complexity and enabling a clean integration of the two. I
> should probably add that I know only very little about the
> dependencies of the various Subversion layers and whether my
> suggestion is feasible at all, but I do know a bit about dependency
> management, continuous integration and building Java/JNN stuff, so I'm
> not purely an armchair advisor. ;)
>
> IMHO it would be great if JavaSVN would completely play the role of
> the JavaHL interfaces that can act as 'client' and replace the
> corresponding JavaHL client interfaces. Anything that JavaSVN cannot
> do - e.g.
> "server-side" things - can continue to be wrapped on top of native
> SVN.
> While both should ideally be in a single tree, it would be helpful if
> the resulting JARs were separate - on without native dependency for
> easy IDE/app integration of client-side tasks, the other with the
> required native dependency. This would not only enforce consistent
> builds from a single source, but also reduce the size, complexity and
> amount of work going into the JNI mappings.
>
> Now please go ahead and tell me what a boneheaded idea this is. :-)
>
> Holger
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 3 20:23:59 2005