|Re: [jgit-dev] Performance of commit preparation|
On Sat, Oct 23, 2010 at 8:16 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:I agree these could be useful, but we should probably put the layer in
> On Fri, Oct 22, 2010 at 5:08 PM, Matthias Sohn
> <matthias.sohn@xxxxxxxxxxxxxx> wrote:
>> 2010/10/21 Shawn Pearce <spearce@xxxxxxxxxxx>
>>> NIO2 in Java 7 might solve this problem. But right now that isn't
>>> available to us. I keep thinking about doing an optional tiny JNI
>>> layer for JGit that just offers us a handful of helper routines.
>>> Exposing the basics (type, length, last modified time) of POSIX and
>>> Win32 stat system calls is one of those.
>> any hints on which other helpers we would need in addition and
>> how this layer should look like ? I would be willing to try this ...
> I had 5 things in mind that might be useful to JGit:
a separate bundle/fragment, which can be removed if not needed. One of
JGit's strengths over other environments is that it's pure Java, and I
know that makes a difference in some organisations in terms of its
If we put it in its own POM and build it as a fragment (which can be
attached to JGit's bundle) with the interface in the main JGit bundle,
then a Class.forName() inside JGit will do the lookup if it's on the
path (or attached as a fragment) or null if not present.
The JNI code and wiring to jgit is in the base org.eclipse.jgit bundle.
Trying to run at JUnit plugin test from separate test bundle keeps
Any clue what might be wrong ?
Any pointers to working examples appreciated ;-)
Back to the top