Gerrit rest client in Java

[Philipp Altmann]

Hi Gerrit community, 

there are any open changes or projects available to provide a Java lib for Gerrit's REST API?

I currently working on a project where I need the REST API and if there are no ongoing projects where I can join I would like

to start with the basic implementation of a "Gerrit rest client" in Java. 

Cheers

Philipp 

[Edwin Kempin]

This would be great. We already started to add a plugin API in Gerrit that can be used from Gerrit plugins to invoke the REST endpoints.

It would be great if the same API could be implemented as a Java library where a method call triggers a REST request instead of invoking the REST endpoint locally.

 

Cheers

Philipp 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philipp Altmann]

The important use cases for my current project would be:

• Create user
• Set user inactive
• Create groups
• Delete included groups
• Create included groups
• Delete group members
• Insert group members

More or less this would be the starting point to get things done. 

// Philipp 

[Luca Milanesio]

Excellent idea, but we need to sort out the HTTP authentication on REST API ;-(

AFAIK it is still quite strict as it uses the X-Gerrit-Auth HTTP Header (+ a valid Gerrit Token): it can be managed in the Java Client library but it would be nice to have something easier.

Luca.

[Shawn Pearce]

On Fri, Mar 7, 2014 at 8:17 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:
> Excellent idea, but we need to sort out the HTTP authentication on REST API
> ;-(
>
> AFAIK it is still quite strict as it uses the X-Gerrit-Auth HTTP Header (+ a
> valid Gerrit Token): it can be managed in the Java Client library but it
> would be nice to have something easier.

Authenticate with HTTP Digest auth and username and the Gerrit
generated password (aka "Git access"). This does not require the
X-Gerrit-Auth header to access the API.

[Shawn Pearce]

On Fri, Mar 7, 2014 at 7:40 AM, Edwin Kempin <edwin....@gmail.com> wrote:
> 2014-03-07 16:36 GMT+01:00 Philipp Altmann <altmann...@gmail.com>:
>
>> Hi Gerrit community,
>>
>> there are any open changes or projects available to provide a Java lib for
>> Gerrit's REST API?
>>
>> I currently working on a project where I need the REST API and if there
>> are no ongoing projects where I can join I would like
>> to start with the basic implementation of a "Gerrit rest client" in Java.
>
> This would be great. We already started to add a plugin API in Gerrit that
> can be used from Gerrit plugins to invoke the REST endpoints.

This API was written as a series of interfaces, intentionally so that
we could drop in a different implementation that uses remote access
over HTTP. It can be found in gerrit-extension-api directory, under
src/main/java/com/google/gerrit/extensions/api/:

https://gerrit.googlesource.com/gerrit/+/HEAD/gerrit-extension-api/src/main/java/com/google/gerrit/extensions/api/GerritApi.java

The idea would be to make a class that implements the GerritApi
interface but uses HTTP underneath for its child interfaces.

[Luca Milanesio]

My case was an unlucky one: REST API for generating the HTTP password :-O

Can't use the Digest Auth :-(

---------
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio

[Shawn Pearce]

On Fri, Mar 7, 2014 at 10:13 AM, Luca Milanesio
<luca.mi...@gmail.com> wrote:
> My case was an unlucky one: REST API for generating the HTTP password :-O

Hah!

[u.wo...@gmail.com]

For the gerrit-intellij-plugin [1] I have built some Java API (which is used internally only in the plugin). I think it would be a good idea to split out this code and build a clean API. Will look into this when I find some time.

Bye

urs

[1] https://github.com/uwolfer/gerrit-intellij-plugin

[Luca Milanesio]

Did you use the new Gerrit REST API ?

---------

Sent from my iPhone

Luca Milanesio

Skype: lucamilanesio

--

[Urs Wolfer]

On Saturday, March 8, 2014 11:53:19 AM UTC+1, lucamilanesio wrote:

Did you use the new Gerrit REST API ?

Yes, it's based on the new REST API. It also supports authentication with "X-Gerrit-Auth HTTP Header".

Bye

urs

[Luca Milanesio]

Cool :-)

---------

Sent from my iPhone

Luca Milanesio

Skype: lucamilanesio

[Mark Derricutt]

+1 I have a project in mind that would also be good to reuse this in - assuming I do it in Java/JVM land.

[Urs Wolfer]

I have started splitting the IntelliJ plugin and it's REST-client-code. Now I'm working on implementing the GerritApi-interfaces.

Basic code example:

    GerritApi gerritClient = new GerritRestClientFactory().create(new GerritAuthData.BasicAuthData("http://localhost:8080", "user", "pw"));

    List<ChangeInfo> changes = gerritClient.changes().list();

The HTTP communication part is based on Apache HttpClient 4. For JSON stuff, Gson 2 is used. It supports basic HTTP authentication, also with support for fallback to "X-Gerrit-Auth HTTP Header" (no special handling required in userland code).

Some questions:

1. Is it okay to add API (interfaces) for REST endpoints like Accounts in GerritApi? If I add that interfaces, would it require to implement / change things in the Gerrit codebase?
   
2. How to list (all) changes, projects? I have added to Changes List<ChangeInfo> list()" (see example above).
   
3. At the moment, all the code is in a GitHub repository together with the IntelliJ plugin. Do you have any suggestions for taking it over to gerrit-review?
   
4. A Maven module module where the API (com.google.gerrit.extensions.api.GerritApi) is deployed would simplify life. At the moment, I have copied it into my project. Also, once the Gerrit-Rest-Java-Client is in a good shape, I think I'll create a maven dependency deployed to a maven repository. 

Bye

urs

[David Ostrovsky]

Am Samstag, 19. April 2014 15:25:41 UTC+2 schrieb Urs Wolfer:

See my answers to your questions below.

> 1. Is it okay to add API (interfaces) for REST endpoints like Accounts in GerritApi? If I add that interfaces, would it require to implement / change things in the Gerrit codebase?

I think we want to have the same child interfaces in GerritApi as the current REST endpoints:

rest-api-access

rest-api-accounts

rest-api-changes

rest-api-config

rest-api-groups

rest-api-plugins

rest-api-projects

Currently only two are implemented Changes and Projects. Just add new interface Accounts in the package:

com.google.gerrit.extensions.api.accounts in gerrit-extension-api project.

> 2. How to list (all) changes, projects? I have added to Changes List<ChangeInfo> list()" (see example above).

Well you probably want to limit the result and provide some kind of paging or quering.

Otherwise you are going to get hundreds of thousands of changes, that is probably not what you want. 

> 3. At the moment, all the code is in a GitHub repository together with the IntelliJ plugin. Do you have any suggestions for taking it over to gerrit-review?

I looked into the code on refactor-rest-client branch. Great job, thanks!

I think to import it in one or another form in gerrit-review, the package names must be aligned with gerrit review, so

com.urswolfer.gerrit.client.rest.http.GerritRestClient

becomes:

com.google.gerrit.client.rest.http.GerritRestClient

or some such. And the package com.urswolfer.gerrit.client.rest.bean should be dropped in favor of Gerrit own classes.

I would suggest to create sub-project under gerrit repository: gerrit-rest-client

and put the code under this sub-project. If you want i could create an initial commit and implement BUCK build that produces new (mavenizeable) artifact:

gerrit-rest-client.jar

I would suggest to start small and only import generic stuff and may be implement only two interfaces Changes and Projects that are already there,

and add new stuff as the interfaces are added to the Gerrit Plugin API itself.

> 4. A Maven module module where the API (com.google.gerrit.extensions.api.GerritApi) is deployed would simplify life.

It's already deployed, no need to copy it:

  buck build api_install

And you can consume "extension" or "plugin" api from Maven driven build from local Maven repository.

Or later from Google bucket. Check pom.xml in one of Gerrit plugins (e. g. cookbook-plugin).

[Urs Wolfer]

On Monday, April 21, 2014 6:43:43 PM UTC+2, David Ostrovsky wrote:

Am Samstag, 19. April 2014 15:25:41 UTC+2 schrieb Urs Wolfer:

See my answers to your questions below.

> 1. Is it okay to add API (interfaces) for REST endpoints like Accounts in GerritApi? If I add that interfaces, would it require to implement / change things in the Gerrit codebase?

I think we want to have the same child interfaces in GerritApi as the current REST endpoints:

rest-api-access

rest-api-accounts

rest-api-changes

rest-api-config

rest-api-groups

rest-api-plugins

rest-api-projects

Currently only two are implemented Changes and Projects. Just add new interface Accounts in the package:

com.google.gerrit.extensions.api.accounts in gerrit-extension-api project.

That's what I have done so far. One problem is that adding API requires changes in GerritApiImpl. What's about adding a "default" implementation for every interface (in form of an abstract class in the interface which throws an UnsupportedOperationException)? Then the Impl can extend that abstract class. That would require minimal changes to existing code in com.google.gerrit.server.api and allow better source compatibility for further changes.

What's about adding a "Tools" API also? I need that in my plugin to fetch the commit-msg hook. I know this is not a "real" REST endpoint...

> 2. How to list (all) changes, projects? I have added to Changes List<ChangeInfo> list()" (see example above).

Well you probably want to limit the result and provide some kind of paging or quering.

Otherwise you are going to get hundreds of thousands of changes, that is probably not what you want. 

Probably better call it #query with an optional argument QueryParameter which allows specifying a query string, number of results, ... 

> 3. At the moment, all the code is in a GitHub repository together with the IntelliJ plugin. Do you have any suggestions for taking it over to gerrit-review?

I looked into the code on refactor-rest-client branch. Great job, thanks!

I think to import it in one or another form in gerrit-review, the package names must be aligned with gerrit review, so

com.urswolfer.gerrit.client.rest.http.GerritRestClient

becomes:

com.google.gerrit.client.rest.http.GerritRestClient

or some such. And the package com.urswolfer.gerrit.client.rest.bean should be dropped in favor of Gerrit own classes.

The bean package got dropped in the meantime.

I would suggest to create sub-project under gerrit repository: gerrit-rest-client

and put the code under this sub-project. If you want i could create an initial commit and implement BUCK build that produces new (mavenizeable) artifact:

gerrit-rest-client.jar

I would suggest to start small and only import generic stuff and may be implement only two interfaces Changes and Projects that are already there,

and add new stuff as the interfaces are added to the Gerrit Plugin API itself.

I'll try to extend the extensions-api first. 

[David Ostrovsky]

Am Samstag, 26. April 2014 14:45:46 UTC+2 schrieb Urs Wolfer:

On Monday, April 21, 2014 6:43:43 PM UTC+2, David Ostrovsky wrote:

Am Samstag, 19. April 2014 15:25:41 UTC+2 schrieb Urs Wolfer:

See my answers to your questions below.

> 1. Is it okay to add API (interfaces) for REST endpoints like Accounts in GerritApi? If I add that interfaces, would it require to implement / change things in the Gerrit codebase?

I think we want to have the same child interfaces in GerritApi as the current REST endpoints:

rest-api-access

rest-api-accounts

rest-api-changes

rest-api-config

rest-api-groups

rest-api-plugins

rest-api-projects

Currently only two are implemented Changes and Projects. Just add new interface Accounts in the package:

com.google.gerrit.extensions.api.accounts in gerrit-extension-api project.

That's what I have done so far. One problem is that adding API requires changes in GerritApiImpl. What's about adding a "default" implementation for every interface (in form of an abstract class in the interface which throws an UnsupportedOperationException)?

Sounds reasonable.

 

Then the Impl can extend that abstract class. That would require minimal changes to existing code in com.google.gerrit.server.api and allow better source compatibility for further changes.

What's about adding a "Tools" API also? I need that in my plugin to fetch the commit-msg hook. I know this is not a "real" REST endpoint...

I will let this one for others to decide.

 

> 2. How to list (all) changes, projects? I have added to Changes List<ChangeInfo> list()" (see example above).

Well you probably want to limit the result and provide some kind of paging or quering.

Otherwise you are going to get hundreds of thousands of changes, that is probably not what you want. 

Probably better call it #query with an optional argument QueryParameter which allows specifying a query string, number of results, ... 

Yes, something like that.

 

> 3. At the moment, all the code is in a GitHub repository together with the IntelliJ plugin. Do you have any suggestions for taking it over to gerrit-review?

I looked into the code on refactor-rest-client branch. Great job, thanks!

I think to import it in one or another form in gerrit-review, the package names must be aligned with gerrit review, so

com.urswolfer.gerrit.client.rest.http.GerritRestClient

becomes:

com.google.gerrit.client.rest.http.GerritRestClient

or some such. And the package com.urswolfer.gerrit.client.rest.bean should be dropped in favor of Gerrit own classes.

The bean package got dropped in the meantime.

good.

 

I would suggest to create sub-project under gerrit repository: gerrit-rest-client

and put the code under this sub-project. If you want i could create an initial commit and implement BUCK build that produces new (mavenizeable) artifact:

gerrit-rest-client.jar

I would suggest to start small and only import generic stuff and may be implement only two interfaces Changes and Projects that are already there,

and add new stuff as the interfaces are added to the Gerrit Plugin API itself.

I'll try to extend the extensions-api first. 

+1

[Urs Wolfer]

There is a standalone Java library available now which implements a lot of the Gerrit extensions-API:

https://github.com/uwolfer/gerrit-rest-java-client

There is still going on work on extending the Gerrit extensions-API (some of the API which is implemented is not in the official Gerrit repository yet). Because it is split of the Gerrit IntelliJ plugin, it implements all API which is required there (a lot of the changes-API). At least until all required API is in the official Gerrit repository, it needs to stay a GitHub project.

If you need some other API which is not implemented yet, feel free to implement it and create a push request at GitHub. At the moment, you need to build it with Maven (it's not deployed to an open Maven repository yet).

Bye

urs