Bug 203523 - Public Git API
Public Git API
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Git
7.1
PC Linux
: P1 (vote)
: 7.2
Assigned To: Ondrej Vrabec
issues@versioncontrol
: API, API_REVIEW, PLAN
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-11 14:38 UTC by Ondrej Vrabec
Modified: 2012-03-12 12:33 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ondrej Vrabec 2011-10-11 14:38:14 UTC
Make API in org.netbeans.libs.git public so JDev can use it easily.
Comment 1 Ondrej Vrabec 2012-02-09 09:01:45 UTC
The Git API provided by org.netbeans.libs.git (/libs.git project) is currently a friend one. JDeveloper would like to use the API for their Git support, but that requires the module to provide a public API. So i would like to mark the API public/under development.

The API allows clients to work with git repositories, get information about a git repository, its branches, tags, commits and files and run several git commands that operate with the repository metadata. Besides that it offers the possibility to monitor progress of running commands.
The javadoc is built regularly and can be reviewed at http://bits.netbeans.org/dev/javadoc/ (Git Client Library). It describes the use-cases the API supports.

I'm kindly asking for review of the API, any comments from reviewers and JDev guys is welcome.
Comment 2 Jaroslav Tulach 2012-02-09 09:24:27 UTC
Y01 getClient(...) method caches the instances. Yet the instances are mutable (e.g. init, setCallback). What will happen if two independent parts of the application share the same client?

Y02 The listener pattern is not used according to JavaBeans spec. Listener interface is supposed to extend EventListener. Listener is usually associated with event. It has the nice property, that you can "grow" the callbacks over time. How do you envision your listener interfaces will grow?

Y03 The ProgressMonitor is sort of listener, is not it? If Y01 is solved in a way that GitClient instances are private to the one who holds, them, it would be easier to have addProgressMonitor(...) and simplify signatures of almost all methods.
Comment 3 Ondrej Vrabec 2012-02-13 13:26:21 UTC
> Y01
not exactly, it is just poorly commented in the Javadoc. getClient(path) *always* returns a new instance of the GitClient.java, in other words it is not shared or cached. Cached are only the JGit internal metadata. I renamed the factory class to GitRepository so it is more clear what is cached and what is not. GitRepository has now GitRepository.getInstance(File path) that returns the intance of the class and an instance method getClient() which always returns a new instance of the GitClient
http://hg.netbeans.org/core-main/rev/1cc4f561cd20

> Y02
all listeners now extend from java.util.EventListener
http://hg.netbeans.org/core-main/rev/378ae2dc9120
> Listener is usually associated with event. It has the nice property, that you can "grow" the callbacks over time. How do you envision your listener interfaces will grow
I am fully comfortable with introducing a new listener for another kinds of events to get from the subsystem. The parameters now passed to the notify methods are enough for current clients' needs. However if you think it would be better to pass wrapper event types, i can rewrite it.

> Y03 The ProgressMonitor is sort of listener, is not it?
Just partially. Besides catching string messages from the Git subsystem it has currently one another purpose and that is canceling running commands. This feature cannot be included in a listener and i need to pass it as a parameter to a git command call. I want only the caller of the command to be able to cancel it, so the method signatures would remain the same.
I could split the PM's methods and move the listener-kind methods to a listener if you think that would look better.
Comment 4 DaveE 2012-02-28 10:46:23 UTC
Javadoc at http://bits.netbeans.org/dev/javadoc/ looks good, very informative.
Comment 5 Jaroslav Tulach 2012-03-01 10:39:47 UTC
(In reply to comment #3)
> > Y01
> the intance of the class and an instance method getClient() which always
> returns a new instance of the GitClient

I would suggest renaming the method to createClient() then.
Comment 6 Ondrej Vrabec 2012-03-01 11:06:13 UTC
(In reply to comment #5)
> I would suggest renaming the method to createClient() then.
fixed: core-main #1d2ab46c97ac
Comment 7 Quality Engineering 2012-03-03 11:31:48 UTC
Integrated into 'main-golden', will be available in build *201203030400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/1d2ab46c97ac
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: #203523 - Public Git API
renaming getClient to createClient to indicate that a new  fresh client is always created
Comment 8 Ondrej Vrabec 2012-03-06 09:53:32 UTC
If there are no more objections or requirements, i would like to turn the API to public at the end of this week.
Comment 9 Ondrej Vrabec 2012-03-11 08:52:38 UTC
fix: http://hg.netbeans.org/core-main/rev/2be415b09b49
Comment 10 Quality Engineering 2012-03-12 12:33:06 UTC
Integrated into 'main-golden', will be available in build *201203120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2be415b09b49
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: #203523 - Public Git API
making Git API public


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo