Gerrit 2.9 with Gitblit?

[Magnus Vigerlöf]

Hi,

I'm looking at upgrading a Gerrit server from 2.8.4 to 2.9. Most of it works, but I do have problem with one plugin; Gitblit. Usually I grab all plugins from gerrit.googlesource.com, check out correct branch and build against the correct Gerrit API.

There is a stack-trace in the error_log file at startup (see the end of the post) and after that there is no trace of Gitblit in Gerrit web UI whatsoever (except being listed as a plugin).

I guess there is a version conflict between Lucene in Gerrit vs Gitblit. After all, Gerrit depends on 4.6.0 while Gitblit depends on 3.6.0. So I took the (what I though) the easy way out, and looked at Gitblit 1.6 to see if I could just use it instead of the pre 1.4 version that we've been using for Gerrit 2.8.4. While I looked at the reason for the compile errors I got I found out that Gitblit have been given a major refactoring, and a DI schema has been implemented (Dagger, not Guice).

Soo... My questions to you guys;
Is there any other that has Gitblit running under Gerrit 2.9?
Does anyone have a feeling for how much work it would take to have it working again?
Should I keep my hope up to get it working some day, or should I look at other alternatives?

BR
  Magnus

PS I'm no stranger to do some of the work, but I need your opinions whether it's worth the effort. DS

----
[2014-08-12 15:52:10,961] INFO  org.eclipse.jetty.server.Server : jetty-9.1.0.v20131115
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter : ***********************************************************
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :             _____  _  _    _      _  _  _
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :            |  __ \(_)| |  | |    | |(_)| |
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :            | |  \/ _ | |_ | |__  | | _ | |_
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :            | | __ | || __|| '_ \ | || || __|
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :            | |_\ \| || |_ | |_) || || || |_
[2014-08-12 15:52:11,490] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :             \____/|_| \__||_.__/ |_||_| \__|
[2014-08-12 15:52:11,491] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :                        Gitblit vv2.9
[2014-08-12 15:52:11,491] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter :
[2014-08-12 15:52:11,491] INFO  com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter : ***********************************************************
[2014-08-12 15:52:11,492] INFO  com.gitblit.GitBlit : Gitblit base folder     = /gerrit-2.9/git
[2014-08-12 15:52:11,492] INFO  com.gitblit.GitBlit : Git repositories folder = /gerrit-2.9/git
[2014-08-12 15:52:11,492] INFO  com.gitblit.GitBlit : Gitblit settings        = /gitblit.properties from gitblit plugin jar with values {web.enableRpcAdministration=false, web.authenticateAdminPages=true, web.mountParameters=false, git.cacheRepositoryList=false, web.allowForking=false, web.enableRpcServlet=false, web.authenticateViewPages=true, realm.userService=com.googlesource.gerrit.plugins.gitblit.auth.GerritToGitBlitUserService, git.onlyAccessBareRepositories=true, web.compressedDownloads=zip gz, web.allowAdministration=false, web.enableRpcManagement=false, web.allowCookieAuthentication=true, web.allowZipDownloads=true, git.repositoriesFolder=/gerrit-2.9/git, git.enableGitServlet=false, web.otherUrls=http://{1}@gerrit.homenet.se:8080/{0} ssh://{1}@gerrit.homenet.se:29418/{0}}
[2014-08-12 15:52:11,504] WARN  com.google.gerrit.httpd.plugins.HttpPluginServlet : Plugin gitblit failed to initialize HTTP
javax.servlet.ServletException: java.lang.SecurityException: sealing violation: can't seal package org.apache.lucene.document: already loaded
        at com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter.init(GerritWicketFilter.java:78)
        at com.google.inject.servlet.FilterDefinition.init(FilterDefinition.java:112)
        at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:100)
        at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:224)
        at com.google.gerrit.httpd.plugins.HttpPluginServlet.load(HttpPluginServlet.java:181)
        at com.google.gerrit.httpd.plugins.HttpPluginServlet.install(HttpPluginServlet.java:155)
        at com.google.gerrit.httpd.plugins.HttpPluginServlet.init(HttpPluginServlet.java:135)
        at com.google.inject.servlet.ServletDefinition.init(ServletDefinition.java:119)
        at com.google.inject.servlet.ManagedServletPipeline.init(ManagedServletPipeline.java:84)
        at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:104)
        at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:224)
        at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:137)
        at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:810)
        at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:288)
        at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
        at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
        at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:131)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
        at org.eclipse.jetty.server.Server.start(Server.java:355)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
        at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
        at org.eclipse.jetty.server.Server.doStart(Server.java:324)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
        at com.google.gerrit.pgm.http.jetty.JettyServer$Lifecycle.start(JettyServer.java:121)
        at com.google.gerrit.lifecycle.LifecycleManager.start(LifecycleManager.java:74)
        at com.google.gerrit.pgm.Daemon.start(Daemon.java:288)
        at com.google.gerrit.pgm.Daemon.run(Daemon.java:200)
        at com.google.gerrit.pgm.util.AbstractProgram.main(AbstractProgram.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.google.gerrit.launcher.GerritLauncher.invokeProgram(GerritLauncher.java:166)
        at com.google.gerrit.launcher.GerritLauncher.mainImpl(GerritLauncher.java:93)
        at com.google.gerrit.launcher.GerritLauncher.main(GerritLauncher.java:50)
        at Main.main(Main.java:25)
Caused by: java.lang.SecurityException: sealing violation: can't seal package org.apache.lucene.document: already loaded
        at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:395)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:417)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at com.gitblit.GitBlit.configureContext(GitBlit.java:3507)
        at com.googlesource.gerrit.plugins.gitblit.GerritWicketFilter.init(GerritWicketFilter.java:72)
        ... 39 more
[2014-08-12 15:52:11,508] INFO  org.eclipse.jetty.server.handler.ContextHandler : Started o.e.j.s.ServletContextHandler@112df87{/,file:/gerrit-2.9/tmp/gerrit_3059021253541753927_app/gerrit_war/,AVAILABLE}

----

[David Ostrovsky]

Am Dienstag, 12. August 2014 17:07:45 UTC+2 schrieb Magnus Vigerlöf:

Hi,

I'm looking at upgrading a Gerrit server from 2.8.4 to 2.9. Most of it works, but I do have problem with one plugin; Gitblit. Usually I grab all plugins from gerrit.googlesource.com, check out correct branch and build against the correct Gerrit API.

AFAICT the most recent version of Gitblit plugin is based on outdated Gitblit 1.3.

Gitblit 1.3 is using outdated Lucene version. Gerrit 2.9 is using very recent Lucene version 4.8.1.

I think that the exception you are seeing is the collision between two different Lucene versions in classpath.

As you pointed out newer Gitblit versions are using Dagger DI framework: 1.4, 1.5 and 1.6.

Gitblit master was converted to Guice, but not released yet, upcoming 1.7.

Because Gitblit master was heavily refactored the plugin would need to be rewired.

Luca and James know more (adding them to this thread), but i think there are two approaches here:

* Try to make it work again with Gitblit 1.3 by replacing Lucene and making code adjustment in Gitblit, or

* Rewire the plugin against most recent Gitblit version. I think it makes sense to wait with this step until

Gitblit 1.7 (Guice based) is released.

[Luca Milanesio]

We should upgrade to the latest and greatest GitBlit IMHO

(master version => upcoming 1.7)

It is not a 5' task as GitBlit now is much more powerful and includes code-review functionalities as well: the best would be to "plug" Gerrit as code-review engine and expose GitBlit as well as main UX, with the ability to go back to Gerrit UX at any time when needed.

In my backlog ... just not time to spend on it at the moment :-(

Luca.

[James Moger]

I've basically been taking the summer off from Gitblit. That wasn't the plan, but that is how it has turned out.  Learning new things, trying different stuff - things that will shape future Gitblit development, no doubt.

I will be coming back to active Gitblit development in a few weeks.  There are a few more weekend family trips planned & then it's time to get the kiddies back into the school schedule.

-J

--
--
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.

[Luca Milanesio]

Hi James,

rest and family are always the priority! And always taking time for extra learning always helps.

Can you share your thoughts of where GitBlit future is heading to ? :-)

That would be useful to plan the next steps for the Gerrit plugin integration as well.

Luca.

[James Moger]

​Yeah, I can share my thoughts.

Above is an overview of the architecture progression of the last 18 months of Gitblit releases and a hint of where I think I am going.

Note: Everything is subject to change and the thoughts are in order of increasing anxiety/controversy for readers.  :)

Gitblit is an organic project and it has grown & stretched alot since it started.  Some things have worked well, other things were outgrown and have been replaced.  Everything has been done within a single module/project.  Over the last 18 months I've been breaking that down into logical pieces.  While the project is still monolithic, it is more modular than it appears at first glance.

Thought 1: Break apart the single project into a handful of projects in one repo.  This _may_  also signal a change of build tool. TBD. (Pause for rejoicing)

Gitblit has alot of utility functions that were custom developed because I wanted it to be small & as self-contained as possible.  This has turned out to be a fool's errand since it now depends on so much.

Thought 2: Use Guava, Commons, JodaTime? etc as much as possible instead of internal utility functions, etc.

Gitblit has a functional but incomplete RPC layer and exposes it's internal models through it.

Thought 3: Be RESTful.  Expose models through this interface that are relevant to the RESTful operation, not necessarily internal models.  Integrate a self-documenting Swagger solution.  This allows for better 3rd-party integration and browser-side improvements.

Another thing that has plagued me is url handling.  That is a complicated topic because it is related to both the servlet container & the underlying web framework.

Thought 4: Abolish all url handling issues and adopt a pattern similar to GitHub.

The red semi-circle will no doubt intrigue inquisitive minds.  Wicket.  Wicket has done a great job in allowing me to grow Gitblit.  It was what I knew and I counted that as an advantage when I started Gitblit (under the theory "don't start with too many completely new things all at once").

Wicket has many great advantages and some awful disadvantages.  Perhaps the biggest issue I have with Wicket (aside from url handling) is it's stateful nature - everything from sessions to page stores.  Ick.  It is not a good fit for how I want the Gitblit UI to operate - stateless.

Wicket 4 (1.4).  That is what Gitblit uses.  Since then the Wicket project has gone through 5 and 6 and I suspect they are working on 7 now.  It is non-trivial to upgrade as there are subtle behavioral gotchas in 4 that I have worked around and major API changes in 5 & 6.

Bootstrap 2.0.x. That is what Gitblit uses.  Gitblit was an early adopter of Bootstrap and relies on a slightly patched version with many customizations.  Bootstrap 3 changes a lot of the syntax and would be a minor chore to adopt.

Thought 5: Replace the web UI with Something Different (tm).

What is Something Different?  That is open to consideration. Right now I am playing with the Ninja Framework [1] + FreeMarker [2] + Bootstrap3 but I am also quite interested in Groovy's new Template Engine [3,4] which appears to be more performant than FreeMarker [5].

Servlet container choices introduce variability.  Gitblit GO is an integrated stack that can be fully debugged from the top of the stack and into the bowels of Jetty.  It is how Gitblit is developed and I consider it the primary deliverable of the Gitblit project.

Back when I had discrete download counts on GoogleCode, GO downloads outweighed WAR downloads 2:1.  I think alot of people choose it for it's simplicity and many throw it behind a reverse proxy.

Thought 6: Only deliver GO binaries.

Gitblit has gotten heavy and that may only get worse - it's footprint has more than doubled since the initial releases.  The larger the footprint, the longer it takes to do releases, the more storage is consumed on Bintray (or wherever) - especially considering GO+WAR and formerly Express.

Fewer (and perhaps smaller) deliverables would make the project more agile.  The original Gitblit GO releases retrieved Maven dependencies at runtime.  The Capsule[6] project could return this capability in a more manageable way.

Thought 7: Major releases are full binary distributions. Dependency updates are prohibited in point releases and a small/single gitblit.jar is distributed.

Simplicity has been a design requirement since the beginning and limited-format text files (properties, conf, yaml, etc) are the defacto standard for simplicity so settings and data have always been stored in text files.  Then the request for "Projects" came along - a way to group and treat repositories with permissions, metadata, etc.  They are not first class citizens in Gitblit and their metadata presents a persistence conundrum.  I'm not satisfied with the current solution.

Gitblit 1.5 introduced a simple plugin mechanism.  It would be reasonable for a plugin to request persistence from Gitblit.  It can do this for simple settings, but not much else without making assumptions and/or implementing custom storage.

Then there is the as-of-yet-unknown Next Thing which will need persistence.  Multiple text files are not future-ready and they present replication hurdles.

Thought 8: Consider depending on MongoDB or an SQL server.

Why not X, Y, or Z?  Well, maybe them.  This aspect of my thoughts is the least, well, thought-out.  :)  I don't dislike SQL - it's fine.  But I am *interested* in MongoDB so that is the direction I am leaning.

Of course, as stated earlier, all these thoughts are subject to change.  A few things that are clear: Gitblit 2 will be a new repo and pieces will be harvested from the Gitblit 1 repo.  That will allow Gitblit 1.x to be maintained in parallel with Gitblit 2 development.  Gitblit 2 is a playground project right now; nothing is serious or firm.

-J

[1]: http://www.ninjaframework.org
[2]: http://freemarker.org
[3]: http://groovy-lang.org/docs/groovy-2.3.0/html/documentation/markup-template-engine.html
[4]: http://spring.io/blog/2014/05/28/using-the-innovative-groovy-template-engine-in-spring-boot
[5]: https://melix.github.io/blog/2014/02/markuptemplateengine.html
[6]: https://github.com/puniverse/capsule

[James Moger]

Have you considered to use AngularJS? 

Absolutely.  Gitblit 1.x already uses this in a few strategic places but it should definitely be used more.

If you are suggesting SPA... I'm not sure if I am ready to go completely browser-side (if I did I would probably consider AngularDart before AngularJS).  My thought was a hybrid approach would be good.  Use server-side generation for simple things, adopt a client-side strategy for pages or panels where that makes sense.  That is perhaps a conservative approach and similar to how I am using AngularJS now.

A good example would be the repositories page which has several outstanding requests for improvement.  To my mind, that should be partially generated server-side - the header, footer, etc - but the primary page content (repository list/table/datagrid/whatever) should be rendered client-side from data fetched using a RESTful GET to an API method documented by Swagger and re-usable by others.

-J

[David Ostrovsky]

Am Dienstag, 12. August 2014 19:32:16 UTC+2 schrieb lucamilanesio:

We should upgrade to the latest and greatest GitBlit IMHO

(master version => upcoming 1.7)

It is not a 5' task as GitBlit now is much more powerful and includes code-review functionalities as well: the best would be to "plug" Gerrit as code-review engine and expose GitBlit as well as main UX, with the ability to go back to Gerrit UX at any time when needed.

I know.

 

In my backlog ... just not time to spend on it at the moment :-(

That why I suggested to consider to try make Gitblit plugin work

against latest released Gerrit version to help folks out there who

depend on it today and not in two years.

@James how hard would it be to replace Lucene in Gitblit 1.3

with 4.8.1 version (use by Gerrit)? I guess it isn't possible to

disable Lucene in Gitblit entirely?

[Magnus Vigerlöf]

Den onsdagen den 13:e augusti 2014 kl. 00:35:06 UTC+2 skrev James Moger:

​Yeah, I can share my thoughts.

Thanks for the quick replies, and very interesting thoughts of what might come.

It is quite clear that Gitblit is quite (and getting even more) competent and a thought that strikes me is if Gitblit still should be a plugin to gerrit in the form and concept it has been so far?

I can't remember I've read the original intentions with providing Gitblit as a plugin to Gerrit, but what I've seen is that it gives a git-repository centric view of the code (like gitweb/gitiles but with more/better information) that Gerrit itself does not have.

Based on that, the thoughts on modularization, consideration of DB dependency, and what the deliveries might become, maybe what the Gerrit plugin need is only a few of the modules from Gitblit that handles this visualization? Would it be a feasible way to get the same functionality back or would that be even a larger task compared to how it has been included so far?

 /w
 

[James Moger]

@James how hard would it be to replace Lucene in Gitblit 1.3

with 4.8.1 version (use by Gerrit)? I guess it isn't possible to

disable Lucene in Gitblit entirely?

The Lucene service can be disabled.  web.allowLuceneIndexing = false

Even though you can disable it, the service is still referenced and the class is loaded.  That may create class verification errors.  Not sure.

It wouldn't be difficult to adjust Gitblit 1.3 to not even bother with Lucene.  I think it's probably commenting out a few lines of code.

-J

[James Moger]

Actually the entire concept of the Gitblit plugin has always made me scratch my head.

I should think it would be easier to create a git-centric (as you phrased it) viewer plugin designed for Gerrit rather than take a complete alternative git server and shove it inside Gerrit.

-J

--

[Luca Milanesio]

Actually already exists and it called Gitiles

(https://code.google.com/p/gitiles/)

The point of my integration with GitBlit was more than a simple viewer though, even if started with it.

I think GitBlit has a simple and clean user experience for all those who want a Git server without having to necessarily spend a lot of time learning Gerrit.

Additionally provides a lot of "goodies" such as the RSS feeds which are very valuable ... and more recently the tickets reviews.

As both GitBlit and Gerrit a JGit-centric, using them in the same JVM allows to have the best of both worlds :-)

Just need to spend more time on it, but contributions would be more than Welcome :-)

The approach of doing a quick fix for 1.3 and make it work to resume the current status would help, but a much longer term activity is needed to upgrade to the upcoming 1.7 (and 2.0 as well) coming versions.

All the clients I've been talking to came back to me with *very* positive comments about the integration, complaining only on the scalability issues related to Wicket which you mentioned as well.

Hoping to have more time in the near future to integrate the 1.7.

Luca.

[Luca Milanesio]

Agreed: on Gerrit we're actually focusing on removing it completely :-)

Luca

Sent from my iPhone

> On 14 Aug 2014, at 16:37, Florian Zschocke <f.zsc...@gmail.com> wrote:
>
>
> Wow!
>
> The only thing I'd hate to see go is the independence from any other service like a database server.

[James Moger]

Agreed: on Gerrit we're actually focusing on removing it completely :-)

What is the replacement?

-J

[Luca Milanesio]

Git repo itself + Lucene / ElasticSearch for indexing :-)

Sent from my iPhone

On 14 Aug 2014, at 17:05, james...@gitblit.com wrote:

>> Agreed: on Gerrit we're actually focusing on removing it completely :-)
>

[James Moger]

Ah.  Sounds familiar.  :)

-J

--
You received this message because you are subscribed to the Google Groups "gitblit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitblit+u...@googlegroups.com.

[Luca Milanesio]

Hey Santhosh,

please keep in mind that the GitBlit slide-deck you mentioned was put together when Gerrit was at Ver. 2.5 and thus the instructions were related to that version (that was the Gerrit master at that time).

Now situation is much different and you can even find pre-compiled binaries published at:

ci.gerritforge.com

With regards to Ver. 2.9, see below the link to the pre-built binary:

https://ci.gerritforge.com/view/Plugins-stable-2.9/job/Plugin_gitblit_stable-2.9/lastSuccessfulBuild/artifact/target/gitblit-plugin-2.9-SNAPSHOT.jar

See my further feedback below:

On 16 Jun 2015, at 18:42, Santhosh Kumar <santh...@gmail.com> wrote:

  Hi James/Luca,

     I had deployed a gitblit instance and I can able to clone my project and its visible in gitblit UI. Similarly, I have a gerrit UI which currently were not showing any code. Everything is blank. My goal is I have to integrate the gitblit code into gerrit as a code review tool. I tried thishttp://www.slideshare.net/lucamilanesio/gitblit-plugin-for-gerrit-code-review.

Thanks for the feedback, I’ll amend the slides with more up-to-date instructions :-)

I can able to run the maven successfully after clearing so many issues.

That would have been a warning bell … something wasn’t quite right ;-)

But in gerrit UI, I can able to see the blank page with gerrit sections. Can you please help what I am doing wrong here. You have any documentation for gitblit+gerrit.

Not really a way to go … better to start from a “safer” set-up sequence :-)

Please restart with pre-compiled binaries OR compile it using the stable-2.9 branch.

I just installed Gerrit 2.9 + downloaded the GitBlit 1.9 and worked like a charm for me!

HTH

Luca.

[Luca Milanesio]

Hi Santosh,

the steps are quite simple:

- copy the plugin into $GERRIT_SITE/plugins (the stable-X.Y that matches your Gerrit version)

- execute java -jar $GERRIT_SITE/bin/gerrit.war init -d $GERRIT_SITE

- follow the wizard steps of the Gitblit plugin 

- start Gerrit and enjoy :-)

Luca.

On 17 Jun 2015, at 18:58, Santhosh <santh...@gmail.com> wrote:

Hi Luca,

  

   Thanks for you reply.

   I am newbie to this gitblit and gerrit integration. Can you please provide me more details. I have a sent an invite chat to you.

   What I understood from your mail is, I can use the gitblit plug in and gerrit war from jenkins. Mostly I wont need the gerrit.war as I am already using higher version which is 2.11. 

   Can you please walk through the steps to integrate or you have any document. I would really appreciate your help on this.

Santhosh  

[Luca Milanesio]

Have you used GitBlit plugin from stable-2.11 with Gerrit 2.11?

If you use the stable-2.9 on top of a Gerrit 2.11 will clearly not work :-(

HTH

Luca

Sent from my iPhone

On 18 Jun 2015, at 03:32, Santhosh <santh...@gmail.com> wrote:

Hi Luca,

    Just an update. I can able to integrate successfully. Also If i use github-plugin 2.9 jar. I am getting the below exception

   Cannot load plugin gitblit

com.google.inject.CreationException: Unable to create injector, see the following errors:

1) No implementation for com.google.gerrit.httpd.WebSession was bound.

  while locating com.google.inject.Provider<com.google.gerrit.httpd.WebSession>

    for parameter 2 at com.googlesource.gerrit.plugins.gitblit.auth.GerritToGitBlitUserService.<init>(GerritToGitBlitUserService.java:53)

  while locating com.googlesource.gerrit.plugins.gitblit.auth.GerritToGitBlitUserService

    for parameter 0 at com.googlesource.gerrit.plugins.gitblit.app.GerritGitBlit.<init>(GerritGitBlit.java:34)

  at com.googlesource.gerrit.plugins.gitblit.GitBlitServletModule.configureServlets(GitBlitServletModule.java:42)

1 error

at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448)

at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)

at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)

at com.google.inject.internal.InjectorImpl.createChildInjector(InjectorImpl.java:225)

at com.google.gerrit.server.plugins.ServerPlugin.startPlugin(ServerPlugin.java:219)

at com.google.gerrit.server.plugins.ServerPlugin.start(ServerPlugin.java:170)

at com.google.gerrit.server.plugins.PluginLoader.runPlugin(PluginLoader.java:461)

at com.google.gerrit.server.plugins.PluginLoader.rescan(PluginLoader.java:390)

at com.google.gerrit.server.plugins.PluginLoader.start(PluginLoader.java:295)

at com.google.gerrit.lifecycle.LifecycleManager.start(LifecycleManager.java:74)

at com.google.gerrit.pgm.Daemon.start(Daemon.java:293)

at com.google.gerrit.pgm.Daemon.run(Daemon.java:205)

at com.google.gerrit.pgm.util.AbstractProgram.main(AbstractProgram.java:64)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at com.google.gerrit.launcher.GerritLauncher.invokeProgram(GerritLauncher.java:166)

at com.google.gerrit.launcher.GerritLauncher.mainImpl(GerritLauncher.java:93)

at com.google.gerrit.launcher.GerritLauncher.main(GerritLauncher.java:50)

After that I used 2.11 plugin. It got worked.

I am working on now how we can use more extensively the code review with gitblit. Let me know If you have any docs. Thanks a lot again.

On Wed, Jun 17, 2015 at 10:58 AM, Santhosh <santh...@gmail.com> wrote:

Hi Luca,

  

   Thanks for you reply.

   I am newbie to this gitblit and gerrit integration. Can you please provide me more details. I have a sent an invite chat to you.

   What I understood from your mail is, I can use the gitblit plug in and gerrit war from jenkins. Mostly I wont need the gerrit.war as I am already using higher version which is 2.11. 

   Can you please walk through the steps to integrate or you have any document. I would really appreciate your help on this.

Santhosh  

On Wed, Jun 17, 2015 at 2:07 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

[James Moger]

HI Paul,

Moving forward you may be interested in using http://www.ractivejs.org/ I have been very impressed with it's almost-zero learning curve and importantly it plays well with other micro libraries.

At first I thought you mistyped the url - was thinking you meant reactivejs.org.  Ractive looks interesting but I'm not sure I am ready to buy into so much client-side code.

I take a closer look at it later this week, thanks for sharing.

-J