Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Maven/Java Tooling #113

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Improve Maven/Java Tooling #113

wants to merge 18 commits into from

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