Proposal: Gerrit plugin versioning, discovery, installation

[Dave Borowitz]

I'm not trying to sidestep the discussion on the other thread, but I thought it would be useful to have a straw-man proposal covering more than just versioning of each plugin, with an eye towards how to make plugin/extension discovery and installation easier for users of non-core plugins.

The end goal is to make plugin installation and setup as easy as:

  $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

I think it's important to have plugin installation as part of init because plugins can/should define InitSteps, and requiring users to download plugins and rerun init adds quite a bit more friction. My proposal may seem a bit complex, but I would like to keep it as simple as possible while enabling easy plugin management with init.

The first thing we need is a central repository of plugin binaries, to which plugin authors (who need not be Gerrit contributors/maintainers) can contribute their plugins. Shawn and I talked briefly about this last night and one idea was to put each plugin in its own Google Cloud Storage bucket:

  http://storage.cloud.google.com/gerrit-plugin-$pluginname/$pluginname-$version.jar

This bucket is owned by the same Google Group that is listed in Gerrit as the project owner for the plugins/$pluginname project; we need to use separate buckets because Google Cloud Storage only has per-bucket permissions, not per-directory (gerrit-plugins/$pluginname/ uses the ACL on gerrit-plugins). So there is an additional setup step for the Gerrit maintainers when a new plugin project is created, but then it's out of maintainers' hands.

Now, on to versioning. I'm more interested in determining the _Gerrit version(s)_ for each plugin JAR, which ensures init downloads the version that works for it. I'm less interested in how each plugin project does its branching and versioning _of the plugin_, since as far as I'm concerned plugins are independent projects and can set up whatever branch/release process they want.

So, a straw-man proposal for versioning. In its the JAR manifest, each plugin includes (optional) min/max Gerrit versions:

  <Gerrit-MinVersion>2.6</Gerrit-MinVersion>

  <Gerrit-MaxVersion>2.7.*</Gerrit-MaxVersion>

In this example, the plugin works with Gerrit >=2.6 and <2.8. Both endpoints are optional. This can be verified at plugin load time by Gerrit, which should know its running version number. These versions refer to the running Gerrit version, not the compile-time plugin/extension API version, the reason being that a single plugin/extension API JAR may work with more than one running version of Gerrit. Especially for plugins, which can depend on arbitrary parts of Gerrit, it's really up to the plugin developer to know the exact range of compatible versions.

The next issue is how init discovers which plugin version to download. Basically we need to store metadata somewhere for all available plugin versions; downloading entire plugin JARs just to extract the manifest and check the version is dumb. Here are some possibilities, in no particular order:

  -For each $pluginname-$version.jar, store alongside it $pluginname-$version.manifest that is the manifest from the JAR.

  -Store version metadata in the HTTP headers in Google Cloud Storage, like "X-Gerrit-MinVersion: 2.6", "X-Gerrit-MaxVersion: 2.7.*".

  -Encode the Gerrit version number directly in the JAR filename, like $pluginname-$version_gerrit-2.6_gerrit-2.7.*.jar.

  -Store a single $pluginname.versions with simple JSON contents, like {"X.Y": {"gerrit-minversion": "2.6", "gerrit-maxversion": "2.7.*"}}.

These have various advantages and disadvantages, for example the first two are straightforward enough but require the client to poll multiple versions.

One concern I've ignored so far is security: init -p plugin makes it trivially easy to download and run arbitrary code form the internet, and independent permissions for plugin projects means plugin code isn't necessarily audited by Gerrit maintainers. I'm open to suggestions (ACL management, JAR signing, etc.) as to how to deal with this.

Comments welcome.

[Chad Horohoe]

On Thu, Mar 28, 2013 at 10:12 AM, Dave Borowitz <dbor...@google.com> wrote:

I'm not trying to sidestep the discussion on the other thread, but I thought it would be useful to have a straw-man proposal covering more than just versioning of each plugin, with an eye towards how to make plugin/extension discovery and installation easier for users of non-core plugins.

 

The end goal is to make plugin installation and setup as easy as:

  $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

I think it's important to have plugin installation as part of init because plugins can/should define InitSteps, and requiring users to download plugins and rerun init adds quite a bit more friction. My proposal may seem a bit complex, but I would like to keep it as simple as possible while enabling easy plugin management with init.

I agree. I think this is really important if we want plugins to really take off.

 

The first thing we need is a central repository of plugin binaries, to which plugin authors (who need not be Gerrit contributors/maintainers) can contribute their plugins. Shawn and I talked briefly about this last night and one idea was to put each plugin in its own Google Cloud Storage bucket:

  http://storage.cloud.google.com/gerrit-plugin-$pluginname/$pluginname-$version.jar

This bucket is owned by the same Google Group that is listed in Gerrit as the project owner for the plugins/$pluginname project; we need to use separate buckets because Google Cloud Storage only has per-bucket permissions, not per-directory (gerrit-plugins/$pluginname/ uses the ACL on gerrit-plugins). So there is an additional setup step for the Gerrit maintainers when a new plugin project is created, but then it's out of maintainers' hands.

This sounds totally reasonable. My only question is on building--would we want

some kind of shared build system that publishes the jars for us, or will it be up

to the maintainer(s) to build+upload? The latter is probably the path of least

resistance, but it's good to be clear.

 

Now, on to versioning. I'm more interested in determining the _Gerrit version(s)_ for each plugin JAR, which ensures init downloads the version that works for it. I'm less interested in how each plugin project does its branching and versioning _of the plugin_, since as far as I'm concerned plugins are independent projects and can set up whatever branch/release process they want.

So, a straw-man proposal for versioning. In its the JAR manifest, each plugin includes (optional) min/max Gerrit versions:

  <Gerrit-MinVersion>2.6</Gerrit-MinVersion>

  <Gerrit-MaxVersion>2.7.*</Gerrit-MaxVersion>

In this example, the plugin works with Gerrit >=2.6 and <2.8. Both endpoints are optional. This can be verified at plugin load time by Gerrit, which should know its running version number. These versions refer to the running Gerrit version, not the compile-time plugin/extension API version, the reason being that a single plugin/extension API JAR may work with more than one running version of Gerrit. Especially for plugins, which can depend on arbitrary parts of Gerrit, it's really up to the plugin developer to know the exact range of compatible versions.

This all sounds reasonable. And yeah, plugin devs should know what versions of

Gerrit their plugin works for.

 

The next issue is how init discovers which plugin version to download. Basically we need to store metadata somewhere for all available plugin versions; downloading entire plugin JARs just to extract the manifest and check the version is dumb. Here are some possibilities, in no particular order:

  -For each $pluginname-$version.jar, store alongside it $pluginname-$version.manifest that is the manifest from the JAR.

  -Store version metadata in the HTTP headers in Google Cloud Storage, like "X-Gerrit-MinVersion: 2.6", "X-Gerrit-MaxVersion: 2.7.*".

  -Encode the Gerrit version number directly in the JAR filename, like $pluginname-$version_gerrit-2.6_gerrit-2.7.*.jar.

  -Store a single $pluginname.versions with simple JSON contents, like {"X.Y": {"gerrit-minversion": "2.6", "gerrit-maxversion": "2.7.*"}}.

These have various advantages and disadvantages, for example the first two are straightforward enough but require the client to poll multiple versions.

I kind of like option 4. JSON is easily editable and readable by humans as well as

machines. 

 

One concern I've ignored so far is security: init -p plugin makes it trivially easy to download and run arbitrary code form the internet, and independent permissions for plugin projects means plugin code isn't necessarily audited by Gerrit maintainers. I'm open to suggestions (ACL management, JAR signing, etc.) as to how to deal with this.

Signing would be nice, since then you could specify to only install signed plugins,

or allow unsigned too. Of course the really paranoi^H^H^H^H^H^H^H security-

conscious probably won't use an auto-downloading system and will just fetch the

plugins by hand.

-Chad

[Dave Borowitz]

On Thu, Mar 28, 2013 at 11:20 AM, Chad Horohoe <chor...@wikimedia.org> wrote:

On Thu, Mar 28, 2013 at 10:12 AM, Dave Borowitz <dbor...@google.com> wrote:

I'm not trying to sidestep the discussion on the other thread, but I thought it would be useful to have a straw-man proposal covering more than just versioning of each plugin, with an eye towards how to make plugin/extension discovery and installation easier for users of non-core plugins.

 

The end goal is to make plugin installation and setup as easy as:

  $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

I think it's important to have plugin installation as part of init because plugins can/should define InitSteps, and requiring users to download plugins and rerun init adds quite a bit more friction. My proposal may seem a bit complex, but I would like to keep it as simple as possible while enabling easy plugin management with init.

I agree. I think this is really important if we want plugins to really take off.

 

The first thing we need is a central repository of plugin binaries, to which plugin authors (who need not be Gerrit contributors/maintainers) can contribute their plugins. Shawn and I talked briefly about this last night and one idea was to put each plugin in its own Google Cloud Storage bucket:

  http://storage.cloud.google.com/gerrit-plugin-$pluginname/$pluginname-$version.jar

This bucket is owned by the same Google Group that is listed in Gerrit as the project owner for the plugins/$pluginname project; we need to use separate buckets because Google Cloud Storage only has per-bucket permissions, not per-directory (gerrit-plugins/$pluginname/ uses the ACL on gerrit-plugins). So there is an additional setup step for the Gerrit maintainers when a new plugin project is created, but then it's out of maintainers' hands.

This sounds totally reasonable. My only question is on building--would we want

some kind of shared build system that publishes the jars for us, or will it be up

to the maintainer(s) to build+upload? The latter is probably the path of least

resistance, but it's good to be clear.

Plugin owners are responsible for their own building for now. We have discussed setting up an automated build system (e.g. on a discardable VM) for Gerrit + core plugins, particularly to detect API changes that we're pretty slow at finding right now. Once we have that running it seems possible to open it up to other plugin developers.

 

Now, on to versioning. I'm more interested in determining the _Gerrit version(s)_ for each plugin JAR, which ensures init downloads the version that works for it. I'm less interested in how each plugin project does its branching and versioning _of the plugin_, since as far as I'm concerned plugins are independent projects and can set up whatever branch/release process they want.

So, a straw-man proposal for versioning. In its the JAR manifest, each plugin includes (optional) min/max Gerrit versions:

  <Gerrit-MinVersion>2.6</Gerrit-MinVersion>

  <Gerrit-MaxVersion>2.7.*</Gerrit-MaxVersion>

In this example, the plugin works with Gerrit >=2.6 and <2.8. Both endpoints are optional. This can be verified at plugin load time by Gerrit, which should know its running version number. These versions refer to the running Gerrit version, not the compile-time plugin/extension API version, the reason being that a single plugin/extension API JAR may work with more than one running version of Gerrit. Especially for plugins, which can depend on arbitrary parts of Gerrit, it's really up to the plugin developer to know the exact range of compatible versions.

This all sounds reasonable. And yeah, plugin devs should know what versions of

Gerrit their plugin works for.

 

The next issue is how init discovers which plugin version to download. Basically we need to store metadata somewhere for all available plugin versions; downloading entire plugin JARs just to extract the manifest and check the version is dumb. Here are some possibilities, in no particular order:

  -For each $pluginname-$version.jar, store alongside it $pluginname-$version.manifest that is the manifest from the JAR.

  -Store version metadata in the HTTP headers in Google Cloud Storage, like "X-Gerrit-MinVersion: 2.6", "X-Gerrit-MaxVersion: 2.7.*".

  -Encode the Gerrit version number directly in the JAR filename, like $pluginname-$version_gerrit-2.6_gerrit-2.7.*.jar.

  -Store a single $pluginname.versions with simple JSON contents, like {"X.Y": {"gerrit-minversion": "2.6", "gerrit-maxversion": "2.7.*"}}.

These have various advantages and disadvantages, for example the first two are straightforward enough but require the client to poll multiple versions.

I kind of like option 4. JSON is easily editable and readable by humans as well as

machines. 

 

One concern I've ignored so far is security: init -p plugin makes it trivially easy to download and run arbitrary code form the internet, and independent permissions for plugin projects means plugin code isn't necessarily audited by Gerrit maintainers. I'm open to suggestions (ACL management, JAR signing, etc.) as to how to deal with this.

Signing would be nice, since then you could specify to only install signed plugins,

or allow unsigned too. Of course the really paranoi^H^H^H^H^H^H^H security-

conscious probably won't use an auto-downloading system and will just fetch the

plugins by hand.

Agreed, but I think our level of responsibility as maintainers goes up as we decrease the level of friction, because exactly what we're doing is encouraging less security-conscious people.

 

-Chad

[Shawn Pearce]

On Thu, Mar 28, 2013 at 10:12 AM, Dave Borowitz <dbor...@google.com> wrote:

> I'm not trying to sidestep the discussion on the other thread, but I thought
> it would be useful to have a straw-man proposal covering more than just
> versioning of each plugin, with an eye towards how to make plugin/extension
> discovery and installation easier for users of non-core plugins.
>
> The end goal is to make plugin installation and setup as easy as:
> $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

This would be great. Once this sort of infrastructure works on the
command line from init we have the basics of mapping a plugin name to
a resolved URL. We can reuse this in the web UI to make installation
of a new plugin into a running server easy too. (Of course if those
have an init step its not pretty to install, but lets ignore that for
the sake of argument.)

> I think it's important to have plugin installation as part of init because
> plugins can/should define InitSteps, and requiring users to download plugins
> and rerun init adds quite a bit more friction. My proposal may seem a bit
> complex, but I would like to keep it as simple as possible while enabling
> easy plugin management with init.

init isn't all its cracked up to be. We probably need to go towards
having things configured from the web UI and using configuration from
init to be limited to the bootstrapping necessary to get the web UI
running and accessible by an admin. (Or the SSH port if we assume
things might also be managed there.)

Ideally plugins would be configured through the web interface if they
want fancy editing, but really their configuration settings should be
saved into Git branches somewhere so admins can inspect history of
settings, rollback, etc. That's all pie in the sky.

Really my point is init is good, but we should be trying to think
about moving away from init not cramming more into it. In the medium
term yes, I agree, -p gitiles is a nice way to get the plugin going.

> The first thing we need is a central repository of plugin binaries, to which
> plugin authors (who need not be Gerrit contributors/maintainers) can
> contribute their plugins. Shawn and I talked briefly about this last night
> and one idea was to put each plugin in its own Google Cloud Storage bucket:
>
> http://storage.cloud.google.com/gerrit-plugin-$pluginname/$pluginname-$version.jar

I hate repeating $pluginname here but it makes saving the file very
simple from e.g. wget or a browser.

> This bucket is owned by the same Google Group that is listed in Gerrit as
> the project owner for the plugins/$pluginname project; we need to use
> separate buckets because Google Cloud Storage only has per-bucket
> permissions, not per-directory (gerrit-plugins/$pluginname/ uses the ACL on
> gerrit-plugins). So there is an additional setup step for the Gerrit
> maintainers when a new plugin project is created, but then it's out of
> maintainers' hands.

We can trivially automate this now. Gerrit has create project[1] and
GS has PUT bucket[2] or we can invoke gsutil. The only manual step
will be making sure the Google Group exists to represent the
maintainers of the plugin. We can ask the people who are requesting
the plugin to make this group. The create-project call to Gerrit just
has to list "google/$group...@googlegroups.com" as one of the owners
to bootstrap correctly.

[1] https://gerrit-review.googlesource.com/Documentation/rest-api-projects.html#create-project
[2] https://developers.google.com/storage/docs/reference-methods#putbucket

The hard part is fixing the 8 or so plugins we already have to switch
their maintainer lists over to Google Groups and adjust the ACLs.

> Now, on to versioning. I'm more interested in determining the _Gerrit
> version(s)_ for each plugin JAR, which ensures init downloads the version
> that works for it. I'm less interested in how each plugin project does its
> branching and versioning _of the plugin_, since as far as I'm concerned
> plugins are independent projects and can set up whatever branch/release
> process they want.

Oh hey, so welcome to what P2[3] is. And why P2 sucks. And why P2 is great.

I agree that plugins are independent of Gerrit. *Except* if they are
what we have been calling "core plugins". IMHO if a plugin ships as
part of the standard WAR download we supply then the maintainers of
Gerrit should enforce that its versions match the versions of Gerrit
it comes in. It may be possible that replication-2.7 runs in Gerrit
2.5. But we should stop naming the core plugins 1.0 when it appears in
Gerrit 2.6.

This does mean the core plugin release schedule is hitched to the
Gerrit release schedule. I think this is an incentive to keep a steady
rhythm in the core server package and ship every ~2 months. Plugins
can ship bug fixes as 2.5.0.1 (patch on the plugin that was in 2.5.0)
or as 2.5.1 (plugin shipped as part of 2.5.1 main release), while
features should ship when a new server ships.

If a plugin leaves the core server "release train" then it can start
to version however it wants.

Basically my brain went all explodey trying to package the plugins for
2.6-rc0. The plugins can't be 1.0 here, 1.1 there, 1.2 over here and
Gerrit at 2.6. My brain isn't that smart. Now if the build process was
less messy, or it wasn't the release maintainer's job to deal with
these plugins, it would be more OK that the versions are all over the
board. The fact that Eclipse plugin versions are different from the
versions of Eclipse is OK because its more automatically managed.

[3] P2 is the Eclipse[4] plugin distribution and installation system. It handles
things like checking version ranges and finding the right versions.

[4] Sorry for the Eclipse reference. I have been at EclipseCon this week.

> So, a straw-man proposal for versioning. In its the JAR manifest, each
> plugin includes (optional) min/max Gerrit versions:
> <Gerrit-MinVersion>2.6</Gerrit-MinVersion>
> <Gerrit-MaxVersion>2.7.*</Gerrit-MaxVersion>

How about:

<Gerrit-RuntimeVersion>[2.6,2.8)</Gerrit-RuntimeVersion >

This matches with how the OSGi version format is used. And is easier to read.

> In this example, the plugin works with Gerrit >=2.6 and <2.8. Both endpoints
> are optional. This can be verified at plugin load time by Gerrit, which
> should know its running version number. These versions refer to the running
> Gerrit version, not the compile-time plugin/extension API version, the
> reason being that a single plugin/extension API JAR may work with more than
> one running version of Gerrit. Especially for plugins, which can depend on
> arbitrary parts of Gerrit, it's really up to the plugin developer to know
> the exact range of compatible versions.

Yes. But plugin authors don't want to set the upper bound too tight.
If they do they may need to release a patch to correct the bound if
the plugin is discovered to work on a newer version of Gerrit.
Annoying, right?

Given what we have said thus far about plugin APIs its reasonable to
say [2.6,2.7) and make plugins recheck and re-release when 2.7 comes
out. They maybe can just increase the bound. Or need to ship a new
version for the [2.7,2.8) range.

Hopefully in the future we can get more disciplined about our API
versioning and make this less of an issue.

> The next issue is how init discovers which plugin version to download.
> Basically we need to store metadata somewhere for all available plugin
> versions; downloading entire plugin JARs just to extract the manifest and
> check the version is dumb. Here are some possibilities, in no particular
> order:
>
> -For each $pluginname-$version.jar, store alongside it
> $pluginname-$version.manifest that is the manifest from the JAR.
> -Store version metadata in the HTTP headers in Google Cloud Storage, like
> "X-Gerrit-MinVersion: 2.6", "X-Gerrit-MaxVersion: 2.7.*".
> -Encode the Gerrit version number directly in the JAR filename, like
> $pluginname-$version_gerrit-2.6_gerrit-2.7.*.jar.
> -Store a single $pluginname.versions with simple JSON contents, like
> {"X.Y": {"gerrit-minversion": "2.6", "gerrit-maxversion": "2.7.*"}}.
>
> These have various advantages and disadvantages, for example the first two
> are straightforward enough but require the client to poll multiple versions.

Do not make a file that has to list everything in it. This is very
annoying to manage. So option 4 is out. What about:

http://storage.cloud.google.com/gerrit-plugin-$pluginname/gerrit-2.6/$pluginname-$version.jar
http://storage.cloud.google.com/gerrit-plugin-$pluginname/gerrit-2.6/$pluginname-$version.pkg

The pkg file can be a small block of JSON like you had in option 4.
The gerrit-2.6 directory is the first version of Gerrit this plugin is
supported on.

For discovery a server scans the top level of the bucket looking for
gerrit-x.y directory names and sorting the x.y by a version compare
sort (so int(x) and int(y) not strings). The server starts by looking
in the subdirectory named after its own version, and then the next
oldest version if one doesn't exist for itself. So a 2.8 server would
look at the 2.6 directory if there is no 2.8 or 2.7 directory present.

Within the directory the server lists the pkg files and again ranks
them by the $version string. It downloads the most recent pkg file and
verifies the version range is supportable on this server. If it is, it
can install the plugin.

If a plugin developer identifies that an existing build works on a
more recent server, they just have to update the existing pkg file
with the wider range. Newer servers will still find the older binary
and use it.

This does tie our discovery system to GS, but S3 has a similar way to
list the contents of the bucket, so we could (maybe trivially?)
support either storage system for discovery purposes.

We can't easily discover buckets named gerrit-plugin-*. GS allows
listing buckets in the project managed by Gerrit upstream[5], but this
doesn't help teams that run their own plugin distribution area on
either GS or S3.

[5] https://developers.google.com/storage/docs/json_api/v1/buckets/list


You know our other option is to just jump over to P2 and an OSGi
runtime that P2 knows how to work with. Switch plugin builds to Tycho.
Etc. This might simplify some things, at the expense of making
everything else really freaking complicated to get into place.

I haven't looked at what Sonar or Hudson/Jenkins do for plugin management.

> One concern I've ignored so far is security: init -p plugin makes it
> trivially easy to download and run arbitrary code form the internet, and
> independent permissions for plugin projects means plugin code isn't
> necessarily audited by Gerrit maintainers. I'm open to suggestions (ACL
> management, JAR signing, etc.) as to how to deal with this.

Good point. What Eclipse does is run a JAR signing service where
committers can upload a JAR and ask Eclipse to sign it after verifying
the committer can release code on that project. We could do something
similar in a virtual machine on Google Compute Engine for plugins
built from source code hosted on gerrit-review. Its still up to server
administrators to decide how much they trust code from a particular
plugin development group, but we can at least help them verify it was
built from the sources it claims it was built from by building and
signing the result.

Doing a signing service like this is somewhat annoying. While the
build is running we have to assume the machine is owned by the plugin
developers. So the private key to do the signing can't be on the
machine running the build. So its at least 2 virtual machines, a
trusted master, and a sacrificial host that runs the build and then is
discarded. Fortunately this is something a VM environment is fairly
good at.

[Dariusz Luksza]

On 03/28/2013 03:12 PM, Dave Borowitz wrote:
> I'm not trying to sidestep the discussion on the other thread, but I thought it would be useful to have a straw-man proposal covering more than just versioning of each plugin, with an eye towards how
> to make plugin/extension discovery and installation easier for users of non-core plugins.
>
> The end goal is to make plugin installation and setup as easy as:
> $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

Why not create a web UI for selecting and installing plugins, something like eclipse marketplace. Maybe this should be next step after this one?

> I think it's important to have plugin installation as part of init because plugins can/should define InitSteps, and requiring users to download plugins and rerun init adds quite a bit more friction.
> My proposal may seem a bit complex, but I would like to keep it as simple as possible while enabling easy plugin management with init.
>
> The first thing we need is a central repository of plugin binaries, to which plugin authors (who need not be Gerrit contributors/maintainers) can contribute their plugins. Shawn and I talked briefly
> about this last night and one idea was to put each plugin in its own Google Cloud Storage bucket:
> http://storage.cloud.google.com/gerrit-plugin-$pluginname/$pluginname-$version.jar
> This bucket is owned by the same Google Group that is listed in Gerrit as the project owner for the plugins/$pluginname project; we need to use separate buckets because Google Cloud Storage only has
> per-bucket permissions, not per-directory (gerrit-plugins/$pluginname/ uses the ACL on gerrit-plugins). So there is an additional setup step for the Gerrit maintainers when a new plugin project is
> created, but then it's out of maintainers' hands.

Did you think how 'proprietary' plugins will feet into google's cloud storage? There should be also list of alternative 'plugin repositories' that users can subscribe to. I would even say that
suchlist should be served from gerrit main site, IMO good example here is (yet again) eclipse marketplace where you can use different providers and some of them comes preconfigured with eclipse.


--
Best regards

GSM: +49 017 445 41235
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

[Dariusz Luksza]

On 03/28/2013 10:13 PM, Shawn Pearce wrote:
> Ideally plugins would be configured through the web interface if they
> want fancy editing, but really their configuration settings should be
> saved into Git branches somewhere so admins can inspect history of
> settings, rollback, etc. That's all pie in the sky.

Huge +1 for plugins UI configuration and for keeping it in Git branches. Going even further sys admins can give configuration permissions for given plugin to given group. Of course this will make
project configuration even more complicated ;)

>> (...)

>
> How about:
>
> <Gerrit-RuntimeVersion>[2.6,2.8)</Gerrit-RuntimeVersion >
>
> This matches with how the OSGi version format is used. And is easier to read.

For sure I miss something, but why Gerrit is not using OSGI as plugin infrastructure? For sure this will solve many problems and cut off some discussions like this 'how (and where) store api version
number". With OSGI we could reuse existing plugin architecture and tools like tycho...

[Deniz Türkoglu]

On Thu, Mar 28, 2013 at 11:34 PM, Dariusz Luksza <dariusz...@gmail.com> wrote:

On 03/28/2013 10:13 PM, Shawn Pearce wrote:

Ideally plugins would be configured through the web interface if they
want fancy editing, but really their configuration settings should be
saved into Git branches somewhere so admins can inspect history of
settings, rollback, etc. That's all pie in the sky.

Huge +1 for plugins UI configuration and for keeping it in Git branches. Going even further sys admins can give configuration permissions for given plugin to given group. Of course this will make project configuration even more complicated ;)

I would prefer to keep this to a later stage when we have figured out how to extend the UI easily, both code wise and UX wise. I actually like Dave's initial idea as it keeps it simple and extendable in the long run.

 

(...)

How about:

   <Gerrit-RuntimeVersion>[2.6,2.8)</Gerrit-RuntimeVersion >

This matches with how the OSGi version format is used. And is easier to read.

For sure I miss something, but why Gerrit is not using OSGI as plugin infrastructure? For sure this will solve many problems and cut off some discussions like this 'how (and where) store api version number". With OSGI we could reuse existing plugin architecture and tools like tycho...

+1 OSGI has proven to be a reliable infrastructure. That being said I think we should look at others with big ecosystems that have managed to handle plugins, conflicts and updates efficiently in a very simple manner. A few names in that space are Jenkins and Firefox. A pros/cons of the approaches should shed some light on the discussion.

-deniz 

[Alex Blewitt]

I think having an OSGi plug-in infrastructure would make it easier to extend as it's already a standard used elsewhere. (Pretty much all enterprise Java servers use OSGi, as does tools like Atlassian JIRA and others). I believe that Jenkins uses .xpi files, much like Mozilla plug-ins work. 

However, OSGi also gives extra features such as providing internal/external APIs and a clean model for introspecting the state of the runtime at any point. It also allows components to talk to each other over a standardised interface. 

I think one constraint is to ensure that Gerrit can still be launched with a java -jar gerrit.war, as is done at the moment. Although not a show-stopper, the all-in-one easy launcher is advantageous to a number of people -- though we're already moving past that point with the plugins/ directory anyway. Whether we could do an all-in-one launcher with an OSGi runtime like Equinox or Felix remains to be seen. Other alternatives include using things like the Equinox servlet bridge (to provide drop-in war capabilities) or even PojoSR to provide an OSGi-like environment with a flat classpath.

https://code.google.com/p/pojosr/

Alex

[Jason Axelson]

From a user perspective I'd like to point out that I really like how Jenkins handles plugins.

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

There's a web-ui to search, install and update plugins. Each plugin has a page with a description, installation instructions and source and issue tracking links.

-Jason

--
--
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/groups/opt_out.
 
 

[Thomas Swindells (tswindel)]

+1 on how Jenkins does it, perhaps we can borrow their code?

[Luciano Carvalho]

On Fri, Mar 29, 2013 at 2:28 AM, Thomas Swindells (tswindel) <tswi...@cisco.com> wrote:

+1 on how Jenkins does it, perhaps we can borrow their code?

I agree! The way plugins are handled in Jenkins/Hudson(sigh) are one of the things that made 'em so popular.

You're proposing a borrowing of the wiki page format only right? Because the whole plugin architecture won't match.

[Thomas Swindells (tswindel)]

 

 

From: Luciano Carvalho [mailto:lsca...@gmail.com]
Sent: 29 March 2013 18:24
To: Thomas Swindells (tswindel)
Cc: Jason Axelson; Alex Blewitt; Deniz Türkoglu; Dariusz Luksza; Shawn Pearce; Dave Borowitz; repo-discuss Discussion
Subject: Re: Proposal: Gerrit plugin versioning, discovery, installation

 

On Fri, Mar 29, 2013 at 2:28 AM, Thomas Swindells (tswindel) <tswi...@cisco.com> wrote:

+1 on how Jenkins does it, perhaps we can borrow their code?

 

I agree! The way plugins are handled in Jenkins/Hudson(sigh) are one of the things that made 'em so popular.

You're proposing a borrowing of the wiki page format only right? Because the whole plugin architecture won't match.

[Thomas Swindells] To be honest I’ve no idea how their code works so have no real opinion of how far we can borrow. I don’t know if there is scope to borrow a bit further and include the code which retrieves the list of what plugins are available, whether there are updates to them available, handling downgrading of them and trigger the install etc

[David Ostrovsky]

Let me bring this thread again.

Am Donnerstag, 28. März 2013 15:12:11 UTC+1 schrieb Dave Borowitz:

I'm not trying to sidestep the discussion on the other thread, but I thought it would be useful to have a straw-man proposal covering more than just versioning of each plugin, with an eye towards how to make plugin/extension discovery and installation easier for users of non-core plugins.

The end goal is to make plugin installation and setup as easy as:

  $ java -jar gerrit.war init -d my-site -p gitiles,plugin2,...

Agreed. But almoust one year later nothing happened, may be we can agree on some intermidiate steps?

Create a googe bucket per plugin and assign the ACL to the plugin maintainers, so that at very least:

Plugin maintainers can upload the artifacts, and the plugin user can consume the precompiled plugins,

so basically from one liner goal make it to be two liner (but kind of now and not pie in the sky):

wget http://storage.cloud.google.com/gerrit-plugin-javamelody/2.8/javamelody.jar 

java -jar gerrit.war init -d my-site -p javamelody.jar

Can someone grant me ACL to upload javamelody plugin to google bucket?

[Khai Do]

I agree with David.  I would really like to see something started here.  This is really needed now that plugins are in the fold.  We use plugins in gerrit and since there is no repository for pre-built plugin binaries we need to host and build the plugins ourselves.    Thanks.