You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
Dependency in project should be:
Requirements:
Advantages:
I can write:
in this case my project depends only on gerrit-ssh and some ssh implementation
I can also write:
and in this case my project depends on gerrit-rest and some http connection library
Disadvantages:
The text was updated successfully, but these errors were encountered: