NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[James Linder]

Hello Git Developers and Users,

This summer, New York University held a class called Open Source
Programming.  One of the projects to come out of the class is JavaGit,
an API providing access to git repositories for Java applications.
Today the JavaGit team has released version 0.1.0 Alpha of the JavaGit
API.  The announcement is listed below.

We are looking forward to continuing the project and grow the project
and welcome new volunteers.  So if the project sounds interesting,
check it out and let us know what you think.

Regards,

The JavaGit Team

------------------------------------------------------------
JavaGit Releases Version 0.1.0 Alpha - August 4, 2008

The JavaGit team is pleased to announce the release of JavaGit version
0.1.0 alpha, an API providing access to git repositories from Java
programs. The goal of JavaGit is to bring the power of git to the Java
developer as an API that is intuitive for developers new to git and
developers who are veteran git users.

JavaGit is engineered to provide the developer with access to the raw
git commands through a command API as well as an object API designed
to represent the .git repository, the working tree and other, familiar
git concepts. JavaGit uses the git binaries installed on the host
machine to provide git functionality and has been designed to easily
accommodate additional methods of access to git repositories.

JavaGit is released as open source software under the GNU LGPL license.

For additional information on the JavaGit project, please visit:

   http://www.javagit.com

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Shawn O. Pearce]

James Linder <james.h.linder@gmail.com> wrote:
> This summer, New York University held a class called Open Source
> Programming.  One of the projects to come out of the class is JavaGit,
> an API providing access to git repositories for Java applications.
> Today the JavaGit team has released version 0.1.0 Alpha of the JavaGit
> API.  The announcement is listed below.

This is interesting work.  Competition is good, but I think many
of us, especially those involved in egit and jgit, would wonder
why a new project was started instead of contributing to one that
already is established.
 
> JavaGit is engineered to provide the developer with access to the raw
> git commands through a command API as well as an object API designed
> to represent the .git repository, the working tree and other, familiar
> git concepts. JavaGit uses the git binaries installed on the host
> machine to provide git functionality and has been designed to easily
> accommodate additional methods of access to git repositories.

One of the primary drivers behind why jgit does not call out to C
Git is to remove the need to install Git binaries on the system.
Some of the Eclipse IDE distributions won't bundle a plugin that
depends upon GPL executables, and hence won't bundle an Eclipse
Git plugin like that.

Another is performance.  Although jgit is written in Java it can
beat the performance of C Git for certain operations due to its
ability to avoid fork+exec.  I've actually had a few times where
writing something in Java against jgit turned out to be easier
and faster than writing it in Perl/Python/Tcl/shell against the C
Git binary, because I was able to avoid the fork+exec overheads.
Although I suspect C Git would have performed a lot better if we
had proper library bindings into say Perl.


I would like to correct one statement in both the JavaGit and
gitclipse FAQ's:

>From http://gitclipse.sourceforge.net/docs/faq.php:
> How is this different from egit/jgit?
> 
> Who/What?!

Seriously?  egit and jgit is a 2.5 year old project that has a
Google Summer of Code student working on it this summer, and is
seeing 20+ patch clusters at least once a month on this list.
You cannot really claim we aren't visible in the Git community.

> No seriously, we have a lot of respect for the egit/jgit project
> they have done a lot of good work. There are several things that
> differentiate us.
> 
>     * egit/jgit are being developed together as one project
>     whereas our API is developed seperately by a different team
>     of developers. This allows our development team to focus our
>     development efforts on our plug-in and not get hung up on
>     API issues.

They are only in the same repository because they started out that
way for convience when it comes to committing.  jgit is completely
seperate from egit and comes with a build process to compile a
stand-alone command line interface based entirely on jgit.

The _only_ reason they haven't been split into two different Git
repositories is because we just haven't wanted to slow down our
development for such a trivial administrative item.

If this really was something that was holding back the adoption
of and contribution to jgit, we'd split it tomorrow, and suffer
the pain of needing to segment development branches.

>From http://javagit.sourceforge.net/faq.php:
> How is JavaGit different from Jgit/Egit?
> 
> Who/What?
> 
> No. But seriously now. JavaGit was conceived of as a complementary
> project to the GitClipse projct, an Eclipse plugin to provide git
> support. It was a logical choice for us to split the project into
> the user oriented project, Gitclipse, and the developer oriented
> project, JavaGit. Since the projects are separate, the JavaGit
> project is free to concentrate on providing a top-notch library/API
> for use in other applications.

Oddly enough this is how jgit and egit came along.  I wanted to
build an Eclipse plugin, but also wanted to make sure that the
majority of the implementation code was not tied to the Eclipse
platform APIs or to the UI so that we could reuse it on other
IDEs (e.g. NetBeans), or on build tools (Maven, Ant, ...), or
for a command line based tool (e.g. jgit's .pgm package).

> Jgit/Egit, on the other hand, appear to be tightly integrated with
> Jgit primarily supporting Egit.

That's not really true.  jgit has two major users: egit and its
related jgit.pgm package (which offers a CLI).  Its sad that there
are not yet more jgit users.  But jgit itself has no dependency on
egit, and is not tightly integrated with it.

I could claim that gitclipse and javagit are tightly integrated
because they are both hosted on SVN on sourceforge.net.  That's
about the same level of "tightly integrated" that jgit and egit are.

> Another difference between JavaGit and Jgit/Egit is that the JavaGit
> team wanted to quickly implement access to git repositories. This
> goal lead us to start by forking to git itself to provide git
> functionality. Knowing that this may be a short-term solution,
> we built JavaGit so that we can easily replace the command line
> interface (CLI) functionality with JNI, pure Java, or some other
> implementation in the future. Jgit/Egit only provides a pure Java
> implementation.

Maybe I'm missing something, but I think egit has more features
available in its UI, and all of those are implemented directly
by jgit.  We even have a graphical history viewer with renderers
built in both AWT and SWT, and the SWT one is available in Eclipse.
So I'm not sure I follow this argument that JavaGit enabled the
team to produce an Eclipse plugin that offers more features, quicker.

-- 
Shawn.

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Johannes Schindelin]

Hi,

On Mon, 4 Aug 2008, Shawn O. Pearce wrote:

> James Linder <james.h.linder@gmail.com> wrote:
>
> > Jgit/Egit, on the other hand, appear to be tightly integrated with 
> > Jgit primarily supporting Egit.
> 
> That's not really true.

I started using jgit in a project that is not yet totally public.  It is 
awesome.  (I mean jgit is awesome, even if my project does make me happy, 
too.)

And I absolutely share the puzzlement of Shawn why anybody would try to do 
their own thing in Java, instead of contributing to jgit.

Especially the fact that "JavaGit" seems to repeat the all-to-obvious 
error of Eclipse: to make a platform-independent library that depends on 
platform dependent components.

I find that kind of thinking so strange, to the point that I am really 
amazed enough to want to analyze the brain of the people inventing such 
things.

But hey, maybe there is a deeper point in it that escapes me.

Ciao,
Dscho

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[A Large Angry SCM]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 4 Aug 2008, Shawn O. Pearce wrote:
> 
>> James Linder <james.h.linder@gmail.com> wrote:
>>
>>> Jgit/Egit, on the other hand, appear to be tightly integrated with 
>>> Jgit primarily supporting Egit.
>> That's not really true.
> 
> I started using jgit in a project that is not yet totally public.  It is 
> awesome.  (I mean jgit is awesome, even if my project does make me happy, 
> too.)
> 
> And I absolutely share the puzzlement of Shawn why anybody would try to do 
> their own thing in Java, instead of contributing to jgit.
> 
> Especially the fact that "JavaGit" seems to repeat the all-to-obvious 
> error of Eclipse: to make a platform-independent library that depends on 
> platform dependent components.
> 
> I find that kind of thinking so strange, to the point that I am really 
> amazed enough to want to analyze the brain of the people inventing such 
> things.
> 
> But hey, maybe there is a deeper point in it that escapes me.

You mean like "Why is a project with the goal of bringing the power of 
git to Java developers hosted in svn instead of git"?

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Petr Baudis]

On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:
> And I absolutely share the puzzlement of Shawn why anybody would try to do 
> their own thing in Java, instead of contributing to jgit.
> 
> Especially the fact that "JavaGit" seems to repeat the all-to-obvious 
> error of Eclipse: to make a platform-independent library that depends on 
> platform dependent components.

[Totally naive question coming with no knowledge of actual size of
current JGit's feature set:]

Wouldn't it make sense to have an ability to fall back on Git calls for
functionality that is not implemented natively yet? If you then don't
have Git available, you just don't get the functionality. What's the
catch?


It seems to me that JavaGit's goal is "features, quick!" where JGit's
goal is "functionality, thoroughly". Both goals seem legitimate to me,
but I'm also not sure why didn't JavaGit just extend JGit's missing bits
with native Git calls and instead opted for reimplementation from the
ground up.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Shawn O. Pearce]

Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:
> > And I absolutely share the puzzlement of Shawn why anybody would try to do 
> > their own thing in Java, instead of contributing to jgit.
> > 
> > Especially the fact that "JavaGit" seems to repeat the all-to-obvious 
> > error of Eclipse: to make a platform-independent library that depends on 
> > platform dependent components.
> 
> [Totally naive question coming with no knowledge of actual size of
> current JGit's feature set:]
> 
> Wouldn't it make sense to have an ability to fall back on Git calls for
> functionality that is not implemented natively yet? If you then don't
> have Git available, you just don't get the functionality. What's the
> catch?

Someone else asked to do this in JGit before (it was privately
off-list to Robin and myself).  Both of our responses were that we
were not that interested in having such dependencies in the main
JGit tree at this time, but that JGit is BSD and nothing would stop
them from forking our tree and trying it out.  If there really was
value there we would have to consider merging it back.

Nothing came of it as far as I know.

Someone recently ported git-blame into JGit, and it looks like they
did a good job, but it was a straight C->Java port.  Since JGit
is licensed under the BSD and builtin-blame.c is under the GPL we
couldn't accept it as-is.  That side project produced a lot more
results than anything else of late, but the GPL virual clause kicked
in and prevented direct inclusion.

-- 
Shawn.

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Pieter de Bie]

On 5 aug 2008, at 03:20, Shawn O. Pearce wrote:

> Someone recently ported git-blame into JGit, and it looks like they
> did a good job, but it was a straight C->Java port.  Since JGit
> is licensed under the BSD and builtin-blame.c is under the GPL we
> couldn't accept it as-is.  That side project produced a lot more
> results than anything else of late, but the GPL virual clause kicked
> in and prevented direct inclusion.

Have you asked the author of git-blame (Junio?) if he'd be willing to
relicence it to the JGit licences?

- Pieter

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

[Shawn O. Pearce]

Pieter de Bie <pdebie@ai.rug.nl> wrote:
> On 5 aug 2008, at 03:20, Shawn O. Pearce wrote:
>
>> Someone recently ported git-blame into JGit, and it looks like they
>> did a good job, but it was a straight C->Java port.  Since JGit
>> is licensed under the BSD and builtin-blame.c is under the GPL we
>> couldn't accept it as-is.  That side project produced a lot more
>> results than anything else of late, but the GPL virual clause kicked
>> in and prevented direct inclusion.
>
> Have you asked the author of git-blame (Junio?) if he'd be willing to
> relicence it to the JGit licences?

We started talking about it off-list actually.  I haven't heard
back from Junio yet but I think he was hinting that he is open to
the idea.

-- 
Shawn.