Make and install plugins from a standard directory

[rjrudin]

As an ml-gradle user
I want a deployment to TITLE
So that I don't need to make and install these separately or via custom tasks

• src/main/ml-native-plugins would be the directory ("native plugins" would be the term so there's no confusion with DHF plugins)
• mlNativePluginPaths would function like mlModulePaths
• mlRestApi dependencies will be able to contribute native plugins as well in an ml-native-plugins directory
• Will by necessity (since the Manage API doesn't yet support this) use /v1/eval and some custom code for call the plugin:install function

[prestonmcgowan]

Here is our current gradle tasks for making and installing plugins.

Build: https://github.com/koopjs/koop-provider-marklogic/blob/master/build.gradle#L198
Install: https://github.com/koopjs/koop-provider-marklogic/blob/master/build.gradle#L211

[prestonmcgowan]

The C++ source code we are currently making use of is available at the following link: https://github.com/koopjs/koop-provider-marklogic/tree/1d278665efc98001c3928e9b68ec534c4e6e22f1/src/main/ml-native-plugins

[rjrudin]

@prestonmcgowan @jkerr5 How important is it to have support for uninstalling native plugins when mlUndeploy is run?

My thought is that the name of the directory under src/main/ml-native-plugins would be the "scope" that is passed into http://docs.marklogic.com/plugin:install-from-zip . On undeploy, that scope could be used in the call to http://docs.marklogic.com/plugin:uninstall .

If that works, then uninstalling should be trivial to support.

[rjrudin]

@prestonmcgowan @jkerr5 I'm also thinking that "ml-plugins" is a better name. This feature is generic to ML, not DHF, and ML already has a definition of the term "plugin". ml-gradle is not specific to DHF, so it makes sense for ml-gradle to use the term "plugin" in the same way as ML, and to not try to improve upon it to avoid any confusion with DHF.

[rjrudin]

Ah I see - "native" is the scope, and this feature sounds like it'll be restricted to plugins with a scope of "native".

[prestonmcgowan]

Supporting uninstall is a good idea, honestly I hadn't thought about that ;-) Your approach sounds logical.

We could also call them "ml-extension-plugins" since the namespace for the plugin code is http://marklogic.com/extension/plugin.

[rjrudin]

"ml-plugins" is nice and short, like the other directories (ml-config, ml-modules, ml-schemas, ml-data). Plus, searching on "marklogic plugins" returns https://docs.marklogic.com/guide/app-dev/plugins .

So there's some naming collision between ML plugins and DHF plugins, but I don't want to try to resolve that - going to stick with "plugins".

[rjrudin]

https://github.com/marklogic-community/ml-gradle/wiki/Installing-plugins