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

Support application "packs" #67

Open
tsegismont opened this issue Jan 21, 2019 · 2 comments
Open

Support application "packs" #67

tsegismont opened this issue Jan 21, 2019 · 2 comments

Comments

@tsegismont
Copy link
Collaborator

tsegismont commented Jan 21, 2019

Currently, the starter lets you select dependencies for the project. This is fine for most projects, but some scenarios require more setup. As a start, we could have packs for an application with:

  • service proxies and rxified API, or
  • gRPC server

For such cases, we could have a "pack" input (similar to dependencies) which would generate everything needed.

@danielpetisme
Copy link
Contributor

I think there are couple of concerns to address.

1- What could be the file structure to ease community proposal of "packs"
2- Should it be a static or dynamic pack generation (ie. a pack = an application with service proxies and rxified API or I can choose Service Proxies and Ops and not Rx for instance)
2- Given a pack, What should be the default language support ?

  • We provide an implementation for each Vert.x supported Language
  • Only Java/Kotlin ?
  • Use Vert.X code Generation ?
    3- Should/Could we reuse the the default example repos/starters ?

@tsegismont
Copy link
Collaborator Author

@danielpetisme thanks for the feedback!

What could be the file structure to ease community proposal of "packs"

I believe it could be the same in PR #69

Packs would define a set of dependencies, perhaps force a language, and sometimes require build plugins configuration.

But we'll keep generating empty verticles and test. We don't want to create a code generator. Just create the project base. Then users can go to the guides to copy/past code :)

Should it be a static or dynamic pack generation (ie. a pack = an application with service proxies and rxified API or I can choose Service Proxies and Ops and not Rx for instance)

Packs would be static.

Given a pack, What should be the default language support ?

I expect most packs to tolerate any language. But we could force a language in some cases.

Should/Could we reuse the the default example repos/starters ?

No we shouldn't. The goal is not to create a code generator, but simply to relieve users from the initial setup effort.

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

No branches or pull requests

2 participants