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