Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] [mylyn-reviews-dev] what does gerrit connector use to list projects?
2012/4/6 Shawn Pearce <spearce@xxxxxxxxxxx>
On Fri, Apr 6, 2012 at 08:13,  <james.moger@xxxxxxxxxxx> wrote:
> This is an issue that is near and dear to my heart - although I have
> _completely_ dropped the ball while the EGit team has done alot of heavy
> lifting on my behalf[1].  :-(
>
> When Matthias and I initially exchanged emails about "import from
> Gitblit" he suggested that a standard server interface coupled with a
> standard EGit import might be appropriate.  That sounded great.  The
> plan then diverged a bit to allow UI specialization and custom
> repository sources which also sounded good.
>
> I have reviewed EGit master with Stefan's changes for the clone wizard
> and source providers.  My conclusion is I have no idea how to hack on
> Eclipse/EGit and I have very low motivation to dive into it with the
> spare time I have available.  To that point I am considering
> implementing your new "/project/" REST interface (and possibly your
> existing interface)

Actually its "/projects/". Plural.

> so Gitblit can masquerade as Gerrit to EGit.  I have
> no problem conforming to Gerrit's specification if it means I get free
> repository enumeration in Eclipse.  Of course the downside to that is
> instructing Gitblit users to "import from Gerrit" which feels wrong but
> is a means-to-an-end.

I agree. Having a common network interface reduces code duplication.
But saying "import from Gerrit" is wrong. Maybe if the network
interface is identical it would be trivial for someone on the EGit
team or the Mylyn Reviews team to add an "import from GitBlit" UI
string in the Gerrit connector that uses the same code internally.
:-)
 
Its maybe still odd to tell users to install the Gerrit connector to
talk to GitBlit. But at least once its installed the UI could say the
right thing.

> I still think it would be useful for EGit to specify a generic REST/JSON
> repository enumeration mechanism that Gitblit (and others) can implement
> (maybe this is the time?).  There are advantages to customization
> (pretty icons, messages, etc), but the basics are all the same so why
> _force_ multiple implementations if a basic/common implementation can
> suffice?

True.
 
could you consider to move down the project/repository discovery part of the 
new Gerrit REST API into JGit so that other JGit based servers can reuse it ? 
I think we could find the time to add the corresponding generic connector in 
EGit, we would then also discuss with the Gerrit Connector team if this could 
also replace the specific Gerrit connector instead of adapting that to the 
new REST API.
 
> Do you have a sample of your JSON output?  It looks like it should be a
> GSON-serialized List<ProjectLine> with a special prefix.  It also looks
> like your servlet takes into account authentication and repository
> authorization which fits my needs too.

Its a pretty simple output. The first line is a magic that prevents
cross site scripting inclusion. You can just output it verbatim before
the real JSON output. The real output is a single JSON array of JSON
objects, each object represents a project, with name and description
fields:


curl 'http://127.0.0.1:8080/projects/?format=JSON&d'
)]}'
[
 {
   "name": "external/bison",
   "description": "The bison\n\n\u003c html parser thingy \u003e"
 },
 {
   "name": "external/flex",
   "description": "yay"
 },
 {
   "name": "external/gcc"
 },
 {
   "name": "external/openssl",
   "description": "it does encryption\n\nand other stuff."
 },
 {
   "name": "tools/repo"
 }
]

The query parameter "d" or "description" is a boolean, e.g. "d=1",
"description=true" to mean include the description field, aka the
$GIT_DIR/description file used by gitweb. If its not supplied, only
the names come back:

$ curl 'http://127.0.0.1:8080/projects/?format=JSON'
)]}'
[
 {
   "name": "external/bison"
 },
 {
   "name": "external/flex"
 },
 {
   "name": "external/gcc"
 },
 {
   "name": "external/openssl"
 },
 {
   "name": "tools/repo"
 }
]

Gerrit uses HTTP Digest authentication, and /projects/ assumes by
default anonymous access and doesn't prompt for authentication. If the
user knows they need to authenticate to see a project they might be
interested in, they can force the server to authenticate them by
adding a "/a/" prefix to the URL:

$ curl -v -n --digest 'http://127.0.0.1:8080/a/projects/?format=JSON'
* About to connect() to 127.0.0.1 port 8080 (#0)
*   Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Server auth using Digest with user 'sop'
> GET /a/projects/?format=JSON HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 127.0.0.1:8080
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Fri, 06 Apr 2012 18:13:26 GMT
< WWW-Authenticate: Digest realm="Gerrit Code Review", qop="auth",
nonce="SAdbhkfhZscI4KUHWKJ4WSv1dqcYupp50pM0rQ==$"
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 1284
<
* Ignoring the response-body
* Connection #0 to host 127.0.0.1 left intact
* Issue another request to this URL:
'http://127.0.0.1:8080/a/projects/?format=JSON'
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Server auth using Digest with user 'sop'
> GET /a/projects/?format=JSON HTTP/1.1
> Authorization: Digest username="sop", realm="Gerrit Code Review", nonce="SAdbhkfhZscI4KUHWKJ4WSv1dqcYupp50pM0rQ==$", uri="/a/projects/?format=JSON", cnonce="MzQ5Mzk0", nc=00000001, qop="auth", response="bf09961f41e4ca02c8256684f0fd0c2d"
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 127.0.0.1:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 06 Apr 2012 18:13:26 GMT
< Cache-Control: no-cache, must-revalidate
< Content-Type: application/json;charset=UTF-8
< Content-Length: 234
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
<
)]}'
[
 {
   "name": "external/bison"
 },
 {
   "name": "external/flex"
 },
 {
   "name": "external/gcc"
 },
 {
   "name": "external/openssl"
 },
 {
   "name": "external/widevine"
 },
 {
   "name": "tools/repo"
 }
]
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0


So I would recommend to client applications that if they are given an
identity by their end-user (e.g. username/password pair) they always
use the /a/projects/ form of query. If they don't have this
information, they should use /projects/. This is a unique problem to
Gerrit I think because Gerrit relies on Digest authentication where
the user agent can't just preset the Authorization HTTP header with
the supplied credentials on the first request.
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev



--
Matthias

Back to the top