Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Discouraged access warnings since storage implementations were moved to internal packages

On Wed, Mar 20, 2013 at 5:18 PM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
>> It's not that bad actually. EGit doesn't use that many internal JGit
>> APIs,
>> it just uses the sama API in many places, ie.
> Here's the count:
>   39;
> How else can we access a standard repo?

Applications should try to use Repository, making them more flexible
about different implementations. Use FileRepositoryBuilder to make a
FileRepository if you have one on local filesystem.

>    1;
> Should be API

Yes, probably.

>    2;
> Should be exposed too, split GC, GCImpl

Yes, I think so. Triggering GC should be maybe hung off Repository
somehow so the implementation can be handled by the storage.

>    2;

I don't know what this is for.

>    4;

This is needs to be maybe moved to public API or cleaned up and made
available by public API. I haven't looked into it. I would like to
extend it with more data. E.g. our storage backend that extends DFS
has more data we would like to expose in ReflogEntry instances than
what a plaintext file normally shows.

>    2;
> Should be API in some form. The ReflogReader impl is internal, but
> it's functionality should be exposed. DFS?

Right, this is a huge gap in the API. DFS assumes the implementation
has its own reflog but there is no API to read the reflog. This needs
to be abstracted so the DFS can plug in its own reflog storage.

In our DFS implementation the reflog is in a database table, with
records per entry. No way you are going to scan that using the text
file reader. :-)

>    1 import;
> It should be possible to reconfigure via API

Already done. Use WindowCachConfig.install() to update the global
WindowCache instance.

Back to the top