openwhisk-devtools icon indicating copy to clipboard operation
openwhisk-devtools copied to clipboard

Improve Maven/Java Tooling

Open klcodanr opened this issue 6 years ago • 8 comments

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 avatar Apr 12 '18 14:04 klcodanr

@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

ddragosd avatar Apr 12 '18 21:04 ddragosd

@kameshsampath @gorkem may I ask for your help reviewing this PR, since you made the initial java contributions ?

ddragosd avatar Apr 12 '18 21:04 ddragosd

@ddragosd sure, looking at it

gorkem avatar Apr 12 '18 22:04 gorkem

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 avatar Apr 13 '18 18:04 klcodanr

@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 avatar Apr 13 '18 21:04 gorkem

@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.

klcodanr avatar Apr 15 '18 04:04 klcodanr

The namespace is usually implied by the auth key - you shouldn’t have a single key with more than one namespace associated with it.

rabbah avatar Apr 15 '18 10:04 rabbah

@klcodanr your proposal SGTM

ddragosd avatar Apr 16 '18 22:04 ddragosd