Environment-based config for deploy JAR

[cskeefer]

There are now a few ML9-only execute privileges listed in the role defined at data-explorer-ext-amp-role.json. This prevents the application from deploying to ML8. Using ml-gradle we can define a separate config directory for an ML8 version of the role and use an env-specific properties file to setup mlConfigPaths accordingly. This is great for development. However, we'll need a different solution to support deployment using the JAR. @rjrudin suggested that we add an issue for this. The outcome of this issue could be used to address issue #130.

[rjrudin]

Is the need here then - we want an executable jar that will work on either ML8 or ML9?

Because there are now ML9-only execute privileges involved, is it fair to say that data-explorer requires ML9? I'm wondering - if those execute privileges aren't available, does data-explorer gracefully downgrade so it still runs fine on ML8?

[cskeefer]

I don't think we can require ML9; I think that would leave too many folks out. It's not any new ML9 functionality that is being used, but rather just new privileges that users need to call a function that existed in ML8. For example, while cts:term-query isn't an advertised function, I think any user can call it in ML8. For ML9 they added a special execute privilege that the user has to have to be able to call it.

So ideally, the role would include the two execute privileges in question if being deployed to ML9 and not include them if being deployed to ML8. Another option would be to not be so fine grained with privs and give the role the "security" role, but it's nice to have the minimum amount of privs/roles to do the job.

[rjrudin]

Okay - I'll try a PR today in this project. I think the way this will work is - before the deployment starts, a call can be made to figure out if this is ML9 or greater. If not, the names of the ML9-only privilege files will be ignored. I think that's easier in this context because it's more of a programmatic decision.