Skip to content

Conversation

@klcodanr
Copy link

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.

@ddragosd
Copy link
Contributor

@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
Copy link
Contributor

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

@gorkem
Copy link
Contributor

gorkem commented Apr 12, 2018

@ddragosd sure, looking at it

@klcodanr
Copy link
Author

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.

@gorkem
Copy link
Contributor

gorkem commented Apr 13, 2018

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

@klcodanr
Copy link
Author

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

@rabbah
Copy link
Member

rabbah commented Apr 15, 2018

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

@ddragosd
Copy link
Contributor

@klcodanr your proposal SGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants