Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] JGit Client API

Hi all,

First of all I'd like to thank JGit developers for their project.

I contribute to a couple of Java projects, both use JGit internally. It
happened that they have to share the same code, especially a layer which
represents an interface of git utility. JGit provides an API for
implementing such a functionality, but that API seems is to be quite
low-level. As far as I understand a number of projects rewrite almost
the same code with minor changes to get the same functionality. Among
them EGit, JGit CLI (org.eclipse.jgit.pgm), SmartGit, NBGit (NetBeans
plugin). IntelliJ Idea plugin doesn't use it yet, but they will probably
switch to JGit one day and will face the same problem.

All that code varies a bit, but these changes can be represented by
several parameters of some methods for every sub-command of git
executable. That means that interface could look like as follows:

git log:
LogClient#doLog(List<ObjectId> fromCommits, RevSort sortBy, ...,
ILogHandler handler);

git commit:
CommitClient#doCommit(String message, PersonIndent author, ..., boolean


SVNKit (pure Java implementation of Subversion VCS) solved that problem
by introducing two APIs: low-level and high-level. The last one mirrors
all the sub-commands of svn* utilities (svn, svnadmin, etc). Among
usability advantages there is an opportunity to switch high-level
implementation between two options: native binaries wrapped by JNI code
and pure Java code of SVNKit.

I think similar solution will work for EGit and other JGit related
projects as well.

As I already mentioned, we already started to work on such an
abstraction (in SmarGit), so existing code now can go open source. And
it's our goal. Our ultimate goal is to make this interface basic for
implementing those JGit related tasks which doesn't need low-level
interfaces. In perfect world it would mean that both JGit CLI and EGit
could be implemented on top of such classes :)

>From my understanding extracting of such an interface is not a big
thing, since git/JGit internals are quite compact. It's more trouble to
integrate that solution into existing code. So I come up to community
with such RFC.

Semyon Vadishev.

Back to the top