Re: JavaHL changes as part of package rename

I was told the patch did not make it to the list. Trying again with a
.txt extensions.

On Fri, Feb 12, 2010 at 11:08 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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/
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/