I agree 100% with you on this Alex. We need this code to be its own separate bundle/component and our main library has to work completely without this JNI layer. I would even go so far as to say we should also have a version that forks and runs shell tools like ln -s to create symlinks so that even if we don't have the JNI layer we may still be able to honor symlinks on POSIX systems.
On Oct 23, 2010 12:42 AM, "Alex Blewitt" <
alex.blewitt@xxxxxxxxx> wrote:
> On Sat, Oct 23, 2010 at 8:16 AM, Shawn Pearce <
spearce@xxxxxxxxxxx> wrote:
>> 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:
>
> I agree these could be useful, but we should probably put the layer in
> 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
> adoption.
>
> 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.
>
> Alex
