Scripting plugins: take two

87 views
Skip to first unread message

lucamilanesio

unread,
Apr 1, 2014, 3:29:46 AM4/1/14
to repo-d...@googlegroups.com, Dariusz Luksza, David Ostrovsky
I would like to agree to common approach to start again the Gerrit Scripting Plugins workstream.

We have to admit ... we screwed that up :-( by working in parallel on the same patch-sets, creating looping changes, adding unnecessary dependencies: result is that after 3 days of Hackathon the scripting plugins work is still up in the air.

My proposal is to restart with a different approach (see below):
a) Avoid unncessary changes
b) Avoid unncessary dependencies
c) Avoid the "code-complexity" explosion of the Gerrit Plugin Loader

I think there are two different needs that should be addressed with different *independent* changes:

Need#1: Have declarative plugin dependencies
Need#2: Have the ability for a plugin to register other plugins

If we implement those two needs separaterly and cleanly, without stepping into each other toes, we will be able to:

- Define different form of plugins (directory-based, needed for Angular-Gerrit, script-based, needed for Scala, Groovy and other scripting languages)
- Allow the development of plugins based on other plugins

What do you think ?
Can we start again ? :-)

Luca.

Alex Blewitt

unread,
Apr 1, 2014, 4:25:39 AM4/1/14
to lucamilanesio, repo-d...@googlegroups.com, Dariusz Luksza, David Ostrovsky
It may make sense for the Gerrit plugin loader to use OSGi in order to expose dependencies and register services and bundles. There's a project called peaberry which allows an OSGi runtime to host guice modules and provide services via OSGi bundles. 

Alex 

Sent from my iPhone 5
--
--
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

unread,
Apr 1, 2014, 12:04:55 PM4/1/14
to Alex Blewitt, Dariusz Luksza, David Ostrovsky, repo-d...@googlegroups.com
Hi Alex,
that would address Need#1 (plugins dependencies) but not Need#2 (ability to register plugins from plugins).

@Dariusz / @David: what is your feedback on Need#2 ?

Luca.

Alex Blewitt

unread,
Apr 1, 2014, 1:22:56 PM4/1/14
to Luca Milanesio, Dariusz Luksza, David Ostrovsky, repo-d...@googlegroups.com
OSGi bundles/services can of course register/install other bundles/services. Not sure why you think it wouldn't meet need#2 as well. 

Alex

Sent from my iPhone 5

Dariusz Luksza

unread,
Apr 1, 2014, 1:49:47 PM4/1/14
to Luca Milanesio, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com
I would say that Need#2 excludes Need#3. This will for sure introduce complexity to the Gerrit Plugin Loader. Secondly for me this does not feel right to load "plugin from plugin". How the plugin will
know from where fetch the dependency? Maybe this would require having something like "Plugin Pre Loader" ... but this will adds complexity. IMO this should be solved by some kind of package-manager
something similar to DEB or RPM :) it shouldn't be feature of plugin subsystem, but separate part of environment (it could also be a plugin eg. gerrit-package-manager (GPM :D))

I'm all for using OSGI! It for sure it has solutions for problems that have are already facing in Gerrit plugin implementation and for tons of other problems that are hidden somewhere in the future.
I've discussed briefly this topic with Shawn during last User Conference. Currently there is many obstacles to switch to OSGI (eg. BUCK don't understand it, google "server backend" also, same goes for
community). I still have this on my TODO list (somewhere after SecureStroe, AuthBackend and JS plugins with resources ;))

OSGI has one disadvantage over current impl, it is complicated and IMO not so easy for new commers. In that area current impl excel, since it is only set of additional parameters in MANIFEST.MF,
annotations or guice bindings.


On 04/01/2014 06:04 PM, Luca Milanesio wrote:
> Hi Alex,
> that would address Need#1 (plugins dependencies) but not Need#2 (ability to register plugins from plugins).
>
> @Dariusz / @David: what is your feedback on Need#2 ?
>
> Luca.
>
> On 1 Apr 2014, at 09:25, Alex Blewitt <alex.b...@gmail.com <mailto:alex.b...@gmail.com>> wrote:
>
>> It may make sense for the Gerrit plugin loader to use OSGi in order to expose dependencies and register services and bundles. There's a project called peaberry which allows an OSGi runtime to host
>> guice modules and provide services via OSGi bundles.
>>
>> Alex
>>
>> Sent from my iPhone 5
>>
>> On 1 Apr 2014, at 08:29, lucamilanesio <luca.mi...@gmail.com <mailto:luca.mi...@gmail.com>> wrote:
>>
>>> I would like to agree to common approach to start again the Gerrit Scripting Plugins workstream.
>>>
>>> We have to admit ... we screwed that up :-( by working in parallel on the same patch-sets, creating looping changes, adding unnecessary dependencies: result is that after 3 days of Hackathon the
>>> scripting plugins work is still up in the air.
>>>
>>> My proposal is to restart with a different approach (see below):
>>> a) Avoid unncessary changes
>>> b) Avoid unncessary dependencies
>>> c) Avoid the "code-complexity" explosion of the Gerrit Plugin Loader
>>>
>>> I think there are two different needs that should be addressed with different *independent* changes:
>>>
>>> Need#1: Have declarative plugin dependencies
>>> Need#2: Have the ability for a plugin to register other plugins
>>>
>>> If we implement those two needs separaterly and cleanly, without stepping into each other toes, we will be able to:
>>>
>>> - Define different form of plugins (directory-based, needed for Angular-Gerrit, script-based, needed for Scala, Groovy and other scripting languages)
>>> - Allow the development of plugins based on other plugins
>>>
>>> What do you think ?
>>> Can we start again ? :-)
>>>
>>> Luca.
>>>
>>>
>>> --
>>> --
>>> To unsubscribe, email repo-discuss...@googlegroups.com <mailto: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 <mailto:repo-discuss...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout.
>


--
Best regards

Twitter: @dluksza
GSM: +49 017 445 41235
Blog: http://luksza.org http://javablog.pl
LinkedIn: http://linkedin.com/in/dariuszluksza

Luca Milanesio

unread,
Apr 1, 2014, 2:34:42 PM4/1/14
to Dariusz Luksza, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com

Need#2 load a plugin (e.g. Groovy script) from another plugin (e.g. Groovy scripting provider).

What is Need#3 ?
>
> I would say that Need#2 excludes Need#3. This will for sure introduce complexity to the Gerrit Plugin Loader. Secondly for me this does not feel right to load "plugin from plugin". How the plugin will know from where fetch the dependency?

The Groovy Scripting Provider plugin, is responsible for parsing and loading Groovy scripts. Gerrit plugin loader will only manage classes that expose annotations and implement interfaces.

> Maybe this would require having something like "Plugin Pre Loader" ... but this will adds complexity.

I don't see any value in introducing a preloader in this scenario: can you elaborate ?

> IMO this should be solved by some kind of package-manager something similar to DEB or RPM :)

That's exactly the phase I'm trying to skip: compile + package + install.

> it shouldn't be feature of plugin subsystem, but separate part of environment (it could also be a plugin eg. gerrit-package-manager (GPM :D))

No please :-)

>
> I'm all for using OSGI! It for sure it has solutions for problems that have are already facing in Gerrit plugin implementation and for tons of other problems that are hidden somewhere in the future. I've discussed briefly this topic with Shawn during last User Conference. Currently there is many obstacles to switch to OSGI (eg. BUCK don't understand it, google "server backend" also, same goes for community).

We've discussed the matter multiple times :-) OSGi is overkill for this and requires a packaging anyway: I want to allow people to extend Gerrit using a simple IDE+compile+package tool known as VI :-)

> I still have this on my TODO list (somewhere after SecureStroe, AuthBackend and JS plugins with resources ;))
>

You TODO is getting too long I'm afraid :-(

Mark Derricutt

unread,
Apr 1, 2014, 3:32:21 PM4/1/14
to Dariusz Luksza, Luca Milanesio, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com
On 2 Apr 2014, at 6:49, Dariusz Luksza wrote:

> Currently there is many obstacles to switch to OSGI (eg. BUCK don't
> understand it,

As far as BUCK not understanding it - BUCK didn't even understand maven,
or frankly - anything real-world usable in a scalable manner -
technically AFAIK it still doesn't, since we still use the Gerrit fork.

Wrapping bnd/bndtools in BUCK shouldn't be hard - using BND annotations
for services and having BND generate the scr metadata would be good to
keeping service registration/dependency fairly simple. I've not looked
at how the BUCK extensions are written tho - that's all python yes?

On the OSGi side itself, one could even publish an OBR repository of
OSGi bundles for an "app store" like setup.

Jonathan Nieder

unread,
Apr 1, 2014, 3:39:32 PM4/1/14
to Mark Derricutt, Dariusz Luksza, Luca Milanesio, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com
Mark Derricutt wrote:

> technically
> AFAIK it still doesn't, since we still use the Gerrit fork.

Gerrit uses unpatched buck to build these days.
https://gerrit.googlesource.com/buck is just a mirror (convenient in
case someone needs to patch buck again in the future).

Dariusz Luksza

unread,
Apr 1, 2014, 4:19:23 PM4/1/14
to Luca Milanesio, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com
On 04/01/2014 08:34 PM, Luca Milanesio wrote:
>
> Need#2 load a plugin (e.g. Groovy script) from another plugin (e.g. Groovy scripting provider).
>
> What is Need#3 ?

sorry, I messed up this with yours requirements for new scripting plugin implementation and in that context Need#3 is "c) avoid code complexity"

>>
>> I would say that Need#2 excludes Need#3. This will for sure introduce complexity to the Gerrit Plugin Loader. Secondly for me this does not feel right to load "plugin from plugin". How the plugin will know from where fetch the dependency?
>
> The Groovy Scripting Provider plugin, is responsible for parsing and loading Groovy scripts. Gerrit plugin loader will only manage classes that expose annotations and implement interfaces.

During hackathon I had an idea how this "plugin" concept can be even more abstracted. Imagine that Gerrit would support something like "plugin environemnts". Default on "java" is implemented currently
in Gerrit. One could also implement separate environments that would support JavaScript (client side), Groovy, Scala, Ruby, Clojure, JavaScript (client side) etc. Some parts of this approach are
currently in, but other are still missing. So right now plugins are only recognized based on file extension, but (with this approach) they will be recognized by "content" this means that one could
have a plugin that have one ssh command implemented in groovy another in scala, and yet another in clojure. There would be two common containers JAR (or zip) file and directory, then all environments
would iterate over content of that container and load what they could understand.

IMO such apporach would add great flexibility to Gerrit ... but first of all I'm not sure if there is a need for that, also if there would be will to review it and accept...

IMO in this context "groovy provider" is not a plugin, but rather an "environment" that know how to parse *.groovy files and integrate them with Gerrit. This feels more like a workaround then solution
for "problem".

>> Maybe this would require having something like "Plugin Pre Loader" ... but this will adds complexity.
>
> I don't see any value in introducing a preloader in this scenario: can you elaborate ?

So currently David is trying to reimplement part of OSGI that is responsible for bundle dependencies. AFAIR whole work is done around PluginLoader class (with already has more than 1k LOC). IMO either
we would move to OSGI or extract this functionality to separate class (eg. plugin preloader) that would be only responsible of dependency solving it should be able also able to initialize installation
process for dependencies but whole process of auto registering services and binding guice modules should be kept in PluginLoader (as it is today).

Later on this could grow to something like 'gerrit-package-manager'

>> IMO this should be solved by some kind of package-manager something similar to DEB or RPM :)
>
> That's exactly the phase I'm trying to skip: compile + package + install.

IMO you still need to have some additional plugin meta data. Either you will keep that in seam file in some thing like XML formant (<meta></meta><plugin-code></plugin-code) (this is ridiculous) or in
a container (like JAR/ZIP or directory).

IMO my initial idea of loading *.js files directly from 'plugins/' directory was not so good. It should be removed from Gerrit as fast as it is possible, plugins should always be organized in some
kind of 'container', for JS plugins this would be a separate directory where one can store metadata like version, default name, dependencies. We shouldn't multiple plugin conventions, for JS plugin
that also went ridiculous eg.:

To install JavaScript plugin you can put *.js file directly in 'plugin/' directory then file name will be used as plugin name, but if you would need to load additional resources you can create
directory within 'plugins/' and put there init.js ... but if you also like to create and access REST services then you need to put init.js in 'static/' dir and buld JAR file...

This is complicated. IMO there should be only one way to deploy plugin. I have patch series that is changing current implementation in a way that 'plugins/$plugin_name/static/init.js' would be the
only way to register JS plugin with resources in both cases (JAR and directory in 'plugins/').

>> it shouldn't be feature of plugin subsystem, but separate part of environment (it could also be a plugin eg. gerrit-package-manager (GPM :D))
>
> No please :-)

Why not? :)

>>
>> I'm all for using OSGI! It for sure it has solutions for problems that have are already facing in Gerrit plugin implementation and for tons of other problems that are hidden somewhere in the future. I've discussed briefly this topic with Shawn during last User Conference. Currently there is many obstacles to switch to OSGI (eg. BUCK don't understand it, google "server backend" also, same goes for community).
>
> We've discussed the matter multiple times :-) OSGi is overkill for this and requires a packaging anyway: I want to allow people to extend Gerrit using a simple IDE+compile+package tool known as VI :-)

OSGI do not exclude use of VI. We can still add "compatibility" layer that will translate current plugin infrastructure to OSGI ;)

>> I still have this on my TODO list (somewhere after SecureStroe, AuthBackend and JS plugins with resources ;))
>>
>
> You TODO is getting too long I'm afraid :-(

yes... that is unfortunate... what is even worse I don't see any support ;-(

Luca Milanesio

unread,
Apr 1, 2014, 7:11:51 PM4/1/14
to Dariusz Luksza, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com

On 1 Apr 2014, at 21:19, Dariusz Luksza <dariusz...@gmail.com> wrote:

> On 04/01/2014 08:34 PM, Luca Milanesio wrote:
>>
>> Need#2 load a plugin (e.g. Groovy script) from another plugin (e.g. Groovy scripting provider).
>>
>> What is Need#3 ?
>
> sorry, I messed up this with yours requirements for new scripting plugin implementation and in that context Need#3 is "c) avoid code complexity"
>
>>>
>>> I would say that Need#2 excludes Need#3. This will for sure introduce complexity to the Gerrit Plugin Loader. Secondly for me this does not feel right to load "plugin from plugin". How the plugin will know from where fetch the dependency?
>>
>> The Groovy Scripting Provider plugin, is responsible for parsing and loading Groovy scripts. Gerrit plugin loader will only manage classes that expose annotations and implement interfaces.
>
> During hackathon I had an idea how this "plugin" concept can be even more abstracted. Imagine that Gerrit would support something like "plugin environemnts". Default on "java" is implemented currently in Gerrit. One could also implement separate environments that would support JavaScript (client side), Groovy, Scala, Ruby, Clojure, JavaScript (client side) etc. Some parts of this approach are currently in, but other are still missing. So right now plugins are only recognized based on file extension, but (with this approach) they will be recognized by "content" this means that one could have a plugin that have one ssh command implemented in groovy another in scala, and yet another in clojure. There would be two common containers JAR (or zip) file and directory, then all environments would iterate over content of that container and load what they could understand.

That sounds a good idea: why don't you try to push a change for it ?

>
> IMO such apporach would add great flexibility to Gerrit ... but first of all I'm not sure if there is a need for that, also if there would be will to review it and accept...

Yes, but I see the challenge as well: it seems quite a big change and thus would take quite some time to get it reviewed and merged :-(
But still feasible IMHO.

>
> IMO in this context "groovy provider" is not a plugin, but rather an "environment" that know how to parse *.groovy files and integrate them with Gerrit. This feels more like a workaround then solution for "problem".

This is the path we started with David in Match: scripting providers as Gerrit plugins.
If you have another simpler solution to the problem (less code, more readable and easy to be used), please share it with a Change and I'll be happy to review it :-)

>
>>> Maybe this would require having something like "Plugin Pre Loader" ... but this will adds complexity.
>>
>> I don't see any value in introducing a preloader in this scenario: can you elaborate ?
>
> So currently David is trying to reimplement part of OSGI that is responsible for bundle dependencies. AFAIR whole work is done around PluginLoader class (with already has more than 1k LOC). IMO either we would move to OSGI or extract this functionality to separate class (eg. plugin preloader) that would be only responsible of dependency solving it should be able also able to initialize installation process for dependencies but whole process of auto registering services and binding guice modules should be kept in PluginLoader (as it is today).

The bundle dependencies have nothing to do with the scripting: those are the two different and isolated needs that I was trying to separate into different and non dependent changes.

>
> Later on this could grow to something like 'gerrit-package-manager'
>
>>> IMO this should be solved by some kind of package-manager something similar to DEB or RPM :)
>>
>> That's exactly the phase I'm trying to skip: compile + package + install.
>
> IMO you still need to have some additional plugin meta data. Either you will keep that in seam file in some thing like XML formant (<meta></meta><plugin-code></plugin-code) (this is ridiculous) or in a container (like JAR/ZIP or directory).

Let me rephrase this in terms of a script: I need a meta-data XML (!) to write a simple script file to hook into received commit messages for validation ?
Do I need a meta-data XML when I put the Gerrit change-id generation script into .git/hooks ?

>
> IMO my initial idea of loading *.js files directly from 'plugins/' directory was not so good. It should be removed from Gerrit as fast as it is possible, plugins should always be organized in some kind of 'container', for JS plugins this would be a separate directory where one can store metadata like version, default name, dependencies. We shouldn't multiple plugin conventions, for JS plugin that also went ridiculous eg.:
>
> To install JavaScript plugin you can put *.js file directly in 'plugin/' directory then file name will be used as plugin name, but if you would need to load additional resources you can create directory within 'plugins/' and put there init.js ... but if you also like to create and access REST services then you need to put init.js in 'static/' dir and buld JAR file...
>
> This is complicated. IMO there should be only one way to deploy plugin. I have patch series that is changing current implementation in a way that 'plugins/$plugin_name/static/init.js' would be the only way to register JS plugin with resources in both cases (JAR and directory in 'plugins/').

I would disagree and I think you had a good idea :-)

>
>>> it shouldn't be feature of plugin subsystem, but separate part of environment (it could also be a plugin eg. gerrit-package-manager (GPM :D))
>>
>> No please :-)
>
> Why not? :)

Again I am rephrasing the statement in terms of a script: do I need a gerrit-package-manager to write a commit validation hook ?

>
>>>
>>> I'm all for using OSGI! It for sure it has solutions for problems that have are already facing in Gerrit plugin implementation and for tons of other problems that are hidden somewhere in the future. I've discussed briefly this topic with Shawn during last User Conference. Currently there is many obstacles to switch to OSGI (eg. BUCK don't understand it, google "server backend" also, same goes for community).
>>
>> We've discussed the matter multiple times :-) OSGi is overkill for this and requires a packaging anyway: I want to allow people to extend Gerrit using a simple IDE+compile+package tool known as VI :-)
>
> OSGI do not exclude use of VI. We can still add "compatibility" layer that will translate current plugin infrastructure to OSGI ;)

I really like the GitHub philosophy to their development style: they don't drive their product by adopting cool frameworks and technology, but rather by implementing cool user-experience using old-style and simple technology.
I agree that OSGi is cool and I like it (despite its complexity, but we are techies anyway and we can manage it) ... but I wouldn't use OSGi for packaging a simple script file.

I would NOT be happy if Linux would ask me to package an OSGi bundle for my ~/.bashrc ;-)

>
>>> I still have this on my TODO list (somewhere after SecureStroe, AuthBackend and JS plugins with resources ;))
>>>
>>
>> You TODO is getting too long I'm afraid :-(
>
> yes... that is unfortunate... what is even worse I don't see any support ;-(

Small safe changes, useful small features => backlog would empty quite soon :-)

That's my remedy !

Luca.

Dariusz Luksza

unread,
Apr 2, 2014, 2:19:37 AM4/2/14
to Luca Milanesio, Alex Blewitt, David Ostrovsky, repo-d...@googlegroups.com
On Wed, Apr 2, 2014 at 1:11 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:
>>>> I would say that Need#2 excludes Need#3. This will for sure introduce complexity to the Gerrit Plugin Loader. Secondly for me this does not feel right to load "plugin from plugin". How the plugin will know from where fetch the dependency?
>>>
>>> The Groovy Scripting Provider plugin, is responsible for parsing and loading Groovy scripts. Gerrit plugin loader will only manage classes that expose annotations and implement interfaces.
>>
>> During hackathon I had an idea how this "plugin" concept can be even more abstracted. Imagine that Gerrit would support something like "plugin environemnts". Default on "java" is implemented currently in Gerrit. One could also implement separate environments that would support JavaScript (client side), Groovy, Scala, Ruby, Clojure, JavaScript (client side) etc. Some parts of this approach are currently in, but other are still missing. So right now plugins are only recognized based on file extension, but (with this approach) they will be recognized by "content" this means that one could have a plugin that have one ssh command implemented in groovy another in scala, and yet another in clojure. There would be two common containers JAR (or zip) file and directory, then all environments would iterate over content of that container and load what they could understand.
>
> That sounds a good idea: why don't you try to push a change for it ?

How may different changes can one person push simultaneously? Of
course many can be started but it is rather important to finish them
(or some of them) ;) In other words, will try to find time to do some
refactoring in PluginLoader area... but this will for sure collide (or
conflict) with scripting plugins

>>
>> IMO such apporach would add great flexibility to Gerrit ... but first of all I'm not sure if there is a need for that, also if there would be will to review it and accept...
>
> Yes, but I see the challenge as well: it seems quite a big change and thus would take quite some time to get it reviewed and merged :-(
> But still feasible IMHO.

I have same concerns...

>> So currently David is trying to reimplement part of OSGI that is responsible for bundle dependencies. AFAIR whole work is done around PluginLoader class (with already has more than 1k LOC). IMO either we would move to OSGI or extract this functionality to separate class (eg. plugin preloader) that would be only responsible of dependency solving it should be able also able to initialize installation process for dependencies but whole process of auto registering services and binding guice modules should be kept in PluginLoader (as it is today).
>
> The bundle dependencies have nothing to do with the scripting: those are the two different and isolated needs that I was trying to separate into different and non dependent changes.

IMO sooner then later on of script will require another as a
dependency, and then we would end up in the same state, where
additional meta data will be required.

>> Later on this could grow to something like 'gerrit-package-manager'
>>
>>>> IMO this should be solved by some kind of package-manager something similar to DEB or RPM :)
>>>
>>> That's exactly the phase I'm trying to skip: compile + package + install.
>>
>> IMO you still need to have some additional plugin meta data. Either you will keep that in seam file in some thing like XML formant (<meta></meta><plugin-code></plugin-code) (this is ridiculous) or in a container (like JAR/ZIP or directory).
>
> Let me rephrase this in terms of a script: I need a meta-data XML (!) to write a simple script file to hook into received commit messages for validation ?
> Do I need a meta-data XML when I put the Gerrit change-id generation script into .git/hooks ?

.git/hooks is kind of different animal. you can only have one script
file per hook, but in gerrit you can have many script files that are
'hooks'. Therefore for .git/hooks single file approach works.

What I'm proposing is only a small overhead of additional directory in
'plugins/' and name convention for 'main files'. So instead of having
'plugins/hello-1.0.groovy' you will have
'plugins/hello-1.0/init.groovy', thats it! With this approach when one
would need something more advanced eg. default plugin name or
dependency, then such information would be put in
'plugins/hello-1.0/META-INF/MANIFEST.MF' (yes, I want to mimic JAR
directory structure within 'plugins/hello-1.0' directory)

>> IMO my initial idea of loading *.js files directly from 'plugins/' directory was not so good. It should be removed from Gerrit as fast as it is possible, plugins should always be organized in some kind of 'container', for JS plugins this would be a separate directory where one can store metadata like version, default name, dependencies. We shouldn't multiple plugin conventions, for JS plugin that also went ridiculous eg.:
>>
>> To install JavaScript plugin you can put *.js file directly in 'plugin/' directory then file name will be used as plugin name, but if you would need to load additional resources you can create directory within 'plugins/' and put there init.js ... but if you also like to create and access REST services then you need to put init.js in 'static/' dir and buld JAR file...
>>
>> This is complicated. IMO there should be only one way to deploy plugin. I have patch series that is changing current implementation in a way that 'plugins/$plugin_name/static/init.js' would be the only way to register JS plugin with resources in both cases (JAR and directory in 'plugins/').
>
> I would disagree and I think you had a good idea :-)

It was good idea to start but additional complexity arrived later on
therefore right now I don't think that it was so good idea ;)

>>>> it shouldn't be feature of plugin subsystem, but separate part of environment (it could also be a plugin eg. gerrit-package-manager (GPM :D))
>>>
>>> No please :-)
>>
>> Why not? :)
>
> Again I am rephrasing the statement in terms of a script: do I need a gerrit-package-manager to write a commit validation hook ?

If you want to write a script on your own and don't declare
dependencies from other plugins, then you don't need to have package
manager. Package manager would be only needed when "external
dependencies" are required. Gerrit should still be able to handle
simple 'plugins/hello-1.0/init.groovy' file.

>>>> I'm all for using OSGI! It for sure it has solutions for problems that have are already facing in Gerrit plugin implementation and for tons of other problems that are hidden somewhere in the future. I've discussed briefly this topic with Shawn during last User Conference. Currently there is many obstacles to switch to OSGI (eg. BUCK don't understand it, google "server backend" also, same goes for community).
>>>
>>> We've discussed the matter multiple times :-) OSGi is overkill for this and requires a packaging anyway: I want to allow people to extend Gerrit using a simple IDE+compile+package tool known as VI :-)
>>
>> OSGI do not exclude use of VI. We can still add "compatibility" layer that will translate current plugin infrastructure to OSGI ;)
>
> I really like the GitHub philosophy to their development style: they don't drive their product by adopting cool frameworks and technology, but rather by implementing cool user-experience using old-style and simple technology.
> I agree that OSGi is cool and I like it (despite its complexity, but we are techies anyway and we can manage it) ... but I wouldn't use OSGi for packaging a simple script file.
>
> I would NOT be happy if Linux would ask me to package an OSGi bundle for my ~/.bashrc ;-)

IMO this example is over simplified. To use this analogy plugins in
Gerrit should be implemented as one-file-per-extension-point, but they
are actually multiple-file-per-extension-point.

>>>> I still have this on my TODO list (somewhere after SecureStroe, AuthBackend and JS plugins with resources ;))
>>>>
>>>
>>> You TODO is getting too long I'm afraid :-(
>>
>> yes... that is unfortunate... what is even worse I don't see any support ;-(
>
> Small safe changes, useful small features => backlog would empty quite soon :-)
>
> That's my remedy !

Some times this remedy has some side effects, look on my changes for
"javascript plugins with resources" and yours scripting plugins...
both are changing same file, therefore my current approach is to wait
:) (maybe it is not perfect, but at least it require less conflict
resolution ;))

--
Best regards

Luca Milanesio

unread,
Apr 2, 2014, 3:12:50 AM4/2/14
to David Ostrovsky, Dariusz Luksza, Alex Blewitt, repo-d...@googlegroups.com
@David: any comments ? Can we restart with a simpler and less change conflicts ?

I would try to start again pushing changes that have less to impact on the JS work that Dariusz is working on.

The scripting language logic will stay in the scripting provider and outside Gerrit.

I would try as well to avoid to overload the plugin loader with the auto-registration of scripts and rather leaving it as responsibility of the scripting provider.

You changed on plugin dependencies are parallel and independent from the scripting stuff, so you may want to rebase them on the master.

Luca

Sent from my iPhone

lucamilanesio

unread,
Apr 17, 2014, 8:24:45 PM4/17/14
to repo-d...@googlegroups.com, David Ostrovsky, Dariusz Luksza, Alex Blewitt
I have uploaded the new set of Changes for the new approach to Scripting plugins:

They are not anymore specific to Scripting-only and they can be easily used by Dariusz (or anybody else) to implement the directory-plugins or any other type of external plugin form.

Will push in the new few days the changes for Scala-Provider and Groovy-Provider to use the new external plugin provider interface.
Reviews, comments, opinions ... are MORE THAN WELCOME :-)

Luca.

lucamilanesio

unread,
Apr 21, 2014, 7:01:53 PM4/21/14
to repo-d...@googlegroups.com, David Ostrovsky, Dariusz Luksza, Alex Blewitt
I have finalised the Scala provider for the new Scripting Plugin Support - Take Two :-)

The patch for the Groovy provided will come hopefully tomorrow.

I was planning as well to build the Gerrit master + scripting topic on ci.gerritforge.com, so that people can start experimenting the Groovy / Scala scripting *without* having necessarily to go through a Gerrit build.

Luca.

lucamilanesio

unread,
Apr 22, 2014, 8:19:21 PM4/22/14
to repo-d...@googlegroups.com, David Ostrovsky, Dariusz Luksza, Alex Blewitt
All patches have been updated:
- Gerrit
- Scala provider
- Groovy provider

You can get the full set at:

I will be working tomorrow to configure on ci.gerritforge.com a Job for building the entire set and provide a downloadable WAR for testing.

Luca.
Reply all
Reply to author
Forward
0 new messages