James Linder <james.h.linder@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
