[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jgit-dev] Dependency on java.io.File
|
Hi,
as I am new to this mailing list, I will briefly introduce myself:
I am the owner of a small company that is currently developing an inhouse
solution for keeping track of our projects, which also includes GIT/JGIT.
The requirements for our custom solution are so that we must abstract from
java.io.File, so that we can redirect file based access to whatever type
of storage we want. This basically means that we would like to use both
the bare repositories which represent "simple" object storages, and the
working trees in our custom solution.
As JGIT makes heavy use of the java.io.File API, which presents a big
problem to us.
Our proposal would be to delegate the creation of derived classes of
java.io.File to the org.eclipse.jgit.util.FS abstraction layer, using
multiple instance level factory methods, e.g.
FS#createNewFileInstance(...), and FS#createTempFile(...), with
org.eclipse.jgit.util.FS providing for and using the standard java.io.File
API.
That way, the FS implementation can be exchanged, providing a custom
java.io.File implementation in favor of the existing one.
In addition, the existing public APIs would not be changed except for a
few minor changes to the InitCommand and the CloneCommand, where an
additional setBuilder() method has to be introduced in order to "inject" a
builder and the filesystem abstraction layer to be used.
This can be achieved in a backwards compatible way, so that existing code
does not have to be changed.
We are currently working on a patch, involving backwards compatible
changes to the public and internal APIs of the system. However, we would
like to have some input first. What is your opinion on that, would this be
a worthwile effort, especially considering it to get merged into the
upstream repository someday?
Regards
Carsten
--
Carsten Klein
carsten.klein@xxxxxxxxxxxxxxx
www.axn-software.de
