Skip to main content

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

Hello Chris,

I'd like to add some more points to Client API:

I'm sure that current API of JGit is inherited from git internals.
Correct me if I'm wrong, but third parties mostly (if not all) use
command line git, if they want to reuse some of its functionality. At
least I can see a lot of tests for Command Line Interface among git
sources. If one could port that code into JGit, he definitely would use
some abstract layer wrapped by some code which writes output to
stdout/stderr.

>From SVNKit experience we have a couple of use cases when command line
utility built on top of the library is really necessary:

1. Running existing Subversion test framework against jsvn* -- command
line utilities based on SVNKit.
2. There are users of jsvn* utilities on system which doesn't support
native svn implementation but have Java Runtime Environment. Mostly they
are OpenVMS users.

Once JGit have such an API, JGit CLI can be built on top of it. This way
the whole JGit API could be tested by existing tests for git CLI. I
assume JGit has a goal to be fully compatible with git one day.

> But when trying to put the coded needed to trigger a merge
> (http://egit.eclipse.org/r/#change,320)
> into an area where it is reuseable from EGit and JGit CLI I learned that it can
> be tricky.
I agree. The solution is not that obvious. And if JGit is going to be
compatible to git, it makes sense to port corresponding code from git
built-ins. At least always have a look at their code.

> JGit CLI and JGit newbies may wants only Strings as parameters
> because that's what they have in hand and getting from Strings to the correct
> ObjectIDs maybe not straightforward (e.g. getting from a tag-name to the commit
> ID it represents, see proposal #320).
Yes, Client API should be tolerant to newbies. In SmartGit initially we
introduced double-methods -- one with String argument for, say, object
id, and another one with resolved object id, which could appear to be
high level object.

> EGit may want some eventing for progress bars, the option to
> cancel calls to the lib and so on.
In SVNKit we have an event listener interface with its implementations
which prints messages to stdout/stderr or Eclipse related code which is
used by progress monitor. Cancellation is supported by CancelException
and a number of check-points where we check whether user hit a cancel. I
think there will be a lot of such particular problems, hopefully, we
will fix them in order they appear :)

> We started factoring out certain
> parts which are common in EGit/JGit but couldn't finish because lack of time.
Is your code publicly available?


Are there any opinions against proposed interface?

--
Semyon Vadishev.

On 18.03.10 1:39, Christian Halstrick wrote:
> Hi,
>
>   
>> SVNKit (pure Java implementation of Subversion VCS) solved that problem
>> by introducing two APIs: low-level and high-level. The last one mirrors
>>     
> ...
>   
>> I think similar solution will work for EGit and other JGit related
>> projects as well.
>>     
> I do like this idea alot. I had discussions with people working mainly in EGit
> (etc. Stefan, Jens) about exactly this topic. We started factoring out certain
> parts which are common in EGit/JGit but couldn't finish because lack of time.
>
> But when trying to put the coded needed to trigger a merge
> (http://egit.eclipse.org/r/#change,320)
> into an area where it is reuseable from EGit and JGit CLI I learned that it can
> be tricky. A CLI and a Eclipse UI may have different requirements to such an
> common lib. JGit CLI and JGit newbies may wants only Strings as parameters
> because that's what they have in hand and getting from Strings to the correct
> ObjectIDs maybe not straightforward (e.g. getting from a tag-name to the commit
> ID it represents, see proposal #320). On the other hand EGit may already have
> higher level object references which it would like to use when working with the
> high-level API.. EGit may want some eventing for progress bars, the option to
> cancel calls to the lib and so on.
>
> Neverthless I do think that we need a high level interface. I think it
> should have
> the same level of abstraction as what people are used from git
> porcelain comands.
> What I also like is that such the implementation of such an interface
> could serve
> as a good documention for jgit newbies on how to solve basic tasks with jgit.
>
> Ciao
>   Chris
> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jgit-dev
>
>
>   


Back to the top