You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ?
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.
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:
For such cases, we could have a "pack" input (similar to dependencies) which would generate everything needed.
The text was updated successfully, but these errors were encountered: