Proposition of architecture.

[slawekjaranowski]

I congratulate that you separate gerrit-events from jenkins plugins. I know that this library mainly support gerrit events, but if you separate it, maybe you are interested to add some new feature.

My proposition is - create a few modules in gerrit-events project.

• gerrit-objects - contains all gerrit JSON objects transformed to plain java object
• gerrit-connections - interface for connection config, factory
• gerrit-commands - gerrit abstract command impementation and command interface
• gerrit-ssh - implementation of connections config, factory, commands and other which is connected with ssh protocol
• gerrit-rest - implementation of connections config, factory, commands and other which is connected with rest/http protocol
• gerrit-events - gerrit events implementation

Dependency in project should be:

• gerrit-commands - depends on gerrit-connections, gerrit-objects
• gerrit-shh - depends on gerrit-connections, gerrit-command, gerrit-objects
• gerrit-rest - depends on gerrit-connections, gerrit-command, gerrit-objects
• gerrit-events - depends on gerrit-connections, gerrit-objects, gerrit-ssh

Requirements:

• method from commands and events return plain java object from gerrit-objects
• connection factory can be extendable
• modules depend on a minimum number of external libraries

Advantages:

• minimum number of external dependency in other projects
• using plain java object is simpler than using JSON object
• commands are not dependent on protocol ssh / rest we have the same interface so we can easy change protocol in project

I can write:

GerritQuery query = new GerritSshQuery(new SSHConnectio(...))

in this case my project depends only on gerrit-ssh and some ssh implementation

I can also write:

GerritQuery query = new GerritRestQuery(new RestConnectio(...))

and in this case my project depends on gerrit-rest and some http connection library

Disadvantages:

• there may be differences in the amount of commands for ssh and rest
• there may be differences in the amount of returning data for ssh and rest

[rsandell]

I like it! The disadvantages you mention could probably be mitigated a little bit by having a "least common denominator" command interface but at the same time "treat" each individual command method (ssh/rest) as a first class interface. As I've understood the intentions of the Gerrit project; the SSH interface is going away at some point or at least will stop development, and new operations will only be implemented in the rest api.

But another concern is what @rinrinne mentions in #5 that Gerrit plugins can add their own events and commands, so the architecture needs to somehow be prepared for that.

If you want to take a stab at implementing the proposed architecture, then go for it! :) But try to not mess too much with the existing dto classes because that would make backwards compatibility in the Gerrit Trigger quite hard/complex to maintain.

I've personally had some pains with how maven behaves with multi module projects in the past; one of the many reasons for breaking out this module. But it could be that my level of maven knowledge hasn't been good enough.