Best practice for inter-plugin dependencies?

[Kenny Ho]

Hi,

Does anyone know the best way to handle inter-plugin dependencies?  I have a plugin that depends on the hook functionality that used to be part of gerrit but the functionality has been split out as part of a core plugin.  I don't think the plugin exports any library to maven.

1) Should I include the hook plugin's source as submodule and build accordingly?

2) Is there some way to define run-time dependencies either in maven or bazel w/o including the hook source as submodule?

3) Other means that I don't know about?

Regards,

Kenny

[Martin Fick]

Could you explain a bit more about what specifically you are
dependent on so that we can help point you to a solution?

Thanks,

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Kenny Ho]

Hey Martin,

My plugin is currently written against 2.12 but we are planning to
upgrade to 2.14 so I need to update the plugin. The plugin depends on
com.google.gerrit.common.ChangeHooks:
https://gerrit.googlesource.com/plugins/manifest-subscription/+/master/src/main/java/com/amd/gerrit/plugins/manifestsubscription/Utilities.java#125
.

If I remember correctly, I put that in because changes caused by my
plugin was not being replicated. It is totally possible that I have
been doing things wrong and I actually don't need to call changeHook
to have the desired effect (and just looking at this now, I probably
didn't need to call changeHook... not sure what I was thinking.) But
let say if I do in fact need to call ChangeHooks, is there a way for
me to manage the dependencies between my plugin and the Hook plugin:
https://gerrit.googlesource.com/plugins/hooks/+/refs/heads/master/src/main/java/com/googlesource/gerrit/plugins/hooks/GitReferenceUpdated.java
.

Regards,
Kenny

[Martin Fick]

On Monday, June 26, 2017 03:34:07 PM Kenny Ho wrote:
> Hey Martin,
>
> My plugin is currently written against 2.12 but we are
> planning to upgrade to 2.14 so I need to update the
> plugin. The plugin depends on
> com.google.gerrit.common.ChangeHooks:
> https://gerrit.googlesource.com/plugins/manifest-subscript
> ion/+/master/src/main/java/com/amd/gerrit/plugins/manifest
> subscription/Utilities.java#125 .
>
> If I remember correctly, I put that in because changes
> caused by my plugin was not being replicated. It is
> totally possible that I have been doing things wrong and
> I actually don't need to call changeHook to have the
> desired effect (and just looking at this now, I probably
> didn't need to call changeHook... not sure what I was
> thinking.) But let say if I do in fact need to call
> ChangeHooks, is there a way for me to manage the
> dependencies between my plugin and the Hook plugin:
> https://gerrit.googlesource.com/plugins/hooks/+/refs/head
> s/master/src/main/java/com/googlesource/gerrit/plugins/hoo
> ks/GitReferenceUpdated.java .

Generally speaking, there is no way to call code in another
plugin except via some of the extension mechanisms built
into core. Specifically, you can extend ssh and restapi
commands from other plugins by registering DymanicOptions
for the commands in a plugin from another plugin. There are
potentially other DynamicMap/DynamicSet extensions that
might allow you to call code in another plugin, but no
mechanism to just call any code from the other plugin.

You can "pretend" you are calling code from another plugin
by compiling your plugin against the other plugin, but that
code when run will load the classes that you are pretending
are from the other plugin via your plugin's classloader, and
execute it. This can happen whether the other plugin is
loaded or not since you are basically running duplicated
code. This is generally not a great idea, but might be what
you want is some specific case.

So it matters exactly what you are trying to do with the
other plugin to understand how you could depend on it. So
far your example does not seem feasible, but it also seems
like you don't actually want it anyway?

[Kenny Ho]

Yes, I will try to refactor it. Thanks for the clarification Martin.

Kenny