Make and install plugins from a standard directory

marklogic / ml-gradle

Gradle plugin for automating everything involving MarkLogic

Other

72 stars 77 forks source link

Make and install plugins from a standard directory #447

Closed rjrudin closed 5 years ago

rjrudin commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

prestonmcgowan commented 5 years ago

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 commented 5 years ago

"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 commented 5 years ago

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