Renaming the JavaHL classes and providing compatibility wrappers for the old classes has allowed us to make some changes in the new classes, such as dropping deprecated classes and renaming things etc. I took the opportunity to ask the SVNKit developers if there was anything more we could do to help them. They provide a pure-Java implementation of the JavaHL interface and I know they ran into a few areas in our code where we did things that made this difficult.
They provided me the attached patch and accompanying explanation of the changes. It all makes sense to me, but I thought I would run it by the list. A lot of these items, such as creating an interface for SVNAdmin, are really obvious. Maybe the constructor change will be more controversial, but I think it reflects what needs to be done if the JavaHL interface is truly meant to be something that could have alternate implementations. Here is there explanation of the changes in the patch: 1. Changed all package local constructors to public ones. This will let SVNKit keep as much of the SVNKit-code out of the Subversion namespace as possible. Also, current version is not consistent in that aspect, for instance Status class constructor is public while Info2 class has package local one. 2. Added ISVNAdmin interface and made SVNAdmin implement it. As you know, there are two ways SVNKit could be used: 1. User removes svn-javahl.jar and replaces it with svnkit-javahl.jar. In this case original JavaHL classes are replaced with SVNKit ones, in particular SVNClient, SVNAdmin, Path and (in this new version) Version and NativeResources. This is not preferred way to use SVNKit and I would talk of it as of a deprecated one. With that approach it is not possible to switch between implementations without use of a custom class loader. 2. Another, preferred approach, is to work with JavaHL API using its interfaces (ISVNClient) and only depend on particular implementation where instance of certain implementation is instantiated. So, to enable second approach for users who'd like to use SVNAdmin I've added ISVNAdmin interface and made SVNAdmin class implement it. I also moved constant and callback interface defined in the SVNAdmin class to the new ISVNAdmin interface. 3. NativeResources.version field made private and instead NativeResources.getVersion() method added. This modification will let SVNKit provide a replacement of NativeResources class for the "deprecated" approach along with custom getVersion() method implementation. Please let me know what you think on my proposal and whether it will be possible to include this patch into the new version of the API. -- Thanks Mark Phippard http://markphip.blogspot.com/
