On Wed, Mar 5, 2008 at 2:25 PM, Imran M Yousuf <imyousuf@xxxxxxxxx> wrote: > > On Wed, Mar 5, 2008 at 2:15 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > > Imran M Yousuf <imyousuf@xxxxxxxxx> wrote: > > > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans) > > > The aim of the plugin is to integrate GIT with NetBeans using JNI so > > > that any change in the implementation of GIT does not effect the SCM > > > plugins way of work. > > > Language: Java > > > Goal: Make GIT available from IDE for NetBeans users and use GIT using > > > Java Native Interfaces > > > > Interesting, but libgit.a is *not* suitable for embedding inside of > > a JVM. Its no fun when a low level Git function suddenly calls die() > > because it was fed invalid user input like a mistyped branch name. > > Your whole IDE shutsdown without a chance to save files. > > > > So that leaves you with three possible routes: > > > > * Use JNI and libgit.a > > > > Now you have three projects, not one. You first need to make > > libgit.a embeddable. *Then* you can work on a JNI wrapper, > > and finally you can build the UI. > > > > * Use jgit > > > > Its at least 100% pure Java and doesn't have the libgit.a issues > > I mentioned above. Its also got some active developers and its > > userbase is growing. We have been careful to keep jgit such > > that it runs on any J2SE system, and thus does not require an > > Eclipse environment. > > > > * Use java.lang.Process and pipes > > > > Ick. Forking a running JVM, especially one the size of an IDE, > > is not pretty. At least on Windows you have CreateProcess(), > > but on POSIX systems the JVM still does a fork/exec pair, and > > on Solaris that hurts hard when your address space is large. > > > > Of these only the latter two are really viable for any time to come > > (just my opinion, but that's that). jgit is coming along and may > > actually be able to do most of the critical features that an IDE > > demands, especially if more people work on it. The latter option > > is obviously available today, but doesn't offer anything near the > > performance or integration that jgit does. > > > > To start with I was actually thinking of JNI + "exec from C". So later > when libification is completed we can replace the execs with call to > the libs directly instead. Is this a viable fourth option (sorry I > forgot to mention it the first time around)? > Just wanted to add that we can also make them 2 separate projects and the reason I wanted to go with JNI is to take advantage of the new developments of GIT without having to change the API (unless a new release of the API all together). > > > > > > 2. distributed versioned web system backup and restoration framework > > > (GPLv2 with CPE, same as NetBeans) > > > [I am not sure whether this one is even qualifies or not as a GIT > > > Community Project] > > > Language: Java, NetBeans RCP > > > Goal: Develop a framework which can backup and restore data from > > > different components of web application. For example, database, ldap, > > > log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally > > > allow edit and propagation of configuration in distributed nature, > > > system restart, data restore. Also integrate backup and repo maintain > > > to Amazon S3. > > > > Yea, I'm not sure this falls too well under the Git community either. > > I don't doubt that we would have sufficient mentor experience here > > to support such a project, but the outcome in terms of both code and > > a student who is familiar with it would not benefit Git very well, > > if at all. > > > > -- > > Shawn. > > > > > > > > -- > Imran M Yousuf > Entrepreneur & Software Engineer > Smart IT Engineering > Dhaka, Bangladesh > Email: imran@xxxxxxxxxxxxxxxxxxxxxx > Mobile: +880-1711402557 > -- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@xxxxxxxxxxxxxxxxxxxxxx Mobile: +880-1711402557 -- 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
