[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jgit-dev] BaseFetchConnection non public
- From: Shawn Pearce <spearce@xxxxxxxxxxx>
- Date: Mon, 25 Jun 2012 07:06:58 -0700
- Delivered-to: email@example.com
On Mon, Jun 25, 2012 at 6:13 AM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
> I was looking through how AmazonS3 provider works, and many of the jgit.transport classes are package scoped (BaseFetchConnection, BaseConnection, WalkRemoteObjectDatabase).
> This makes writing a new transport more difficult since it either involves gratuitous copy and paste, or putting the class in an org.eclipse.jgit package (which then causes problems in OSGi containers if you aren't deploying as a fragment).
> Is there a reason these classes are private?
I didn't want them part of the public API when we wrote this section
of JGit. I know of only one successful new transport written for
JGit... its an internal one at Google based on our internal RPC
system. It works like the smart HTTP one does, so it reuses the push
and fetch connection implementations, as its just an embedding of
smart HTTP into a non-HTTP transport. This was successful without
needing to be in the org.eclipse.jgit package space, and without
needing to copy and paste code. So its almost possible to implement a
The walk versions like the AmazonS3 probably are based on package
private things, making a new walk transport nearly impossible to
implement. This code has been pretty stable for years, we could expose
more of it as public in the package with sufficient warnings on the
Javadoc that they are low-level implementation primitives used to
build transports, so application developers don't try to use them
directly and complain about how hard it is to fetch or push with JGit.