openwhisk-devtools
openwhisk-devtools copied to clipboard
Improve Maven/Java Tooling
I added some new features to improve the Java tooling for OpenWhisk:
- Annotations which indicate Actions, Packages, Rules and Triggers at a Class level
- Maven plugin to parse the annotations and automatically install the code into OpenWhisk during maven builds
I provided some documentation and reorganized the repo a bit to group the Java dev tools.
@klcodanr this looks really nice.
One thought I have is regarding the deploy process. Are you familiar with wskdeploy ? It has more logic to deploy, update, delete, remove what's changed, etc. I'm wondering if it would be a cleaner approach if we were to use the Java Annotations to generate a wskdeploy
manifest file, and then invoke wskdeploy
from maven ?
cc @mrutkows
@kameshsampath @gorkem may I ask for your help reviewing this PR, since you made the initial java contributions ?
@ddragosd sure, looking at it
So I looked into wskdeploy, looks like a really nice toolset. I was wondering how it would handle if you wanted one or more modules to contribute to a single package? I'm thinking of a case where you'd have some pretty significant dependencies for a set of actions which you don't want to bloat other actions with.
The best solution to me would be to support two different mojos:
- Scan (or something like that) - gather up all of the classes in some identified location and evaluate their annotations
- Update - write out the YAML manifest file and optionally install it into OpenWhisk
so your project could look something like:
- reactor
- module 1 (action 1, 2) (scan)
- module 2 (action 3, 4) (scan)
- module 3 (update)
The artifact for module 3 can then be a ZIP file containing the manifest YAML and all of the previous artifacts required to build it.
@klcodanr I do not see any namespace support on the mojo. Is that by design? This will require CI systems to do extra steps to deploy to a certain namespace.
Also mojo is using the CLI but have you considered using the APIs directly instead of the CLI? I think it would make it more intuitive to use on CI systems.
@gorkem
Namespace - good point, I missed that, I'll add it as a Mojo parameter API vs. CLI - I don't want to reinvent the wheel. The CLI and/or wskdeploy already handle the plumbing of deploying to OpenWhisk, I'm not sure it makes sense to add another implementation to the mix.
The namespace is usually implied by the auth key - you shouldn’t have a single key with more than one namespace associated with it.
@klcodanr your proposal SGTM