Scaffold generation driven by extensions

maxandersen commented 4 years ago

Description

There are various usecases where it is useful where extensions can generate code into users projects and potentially do other actions. Today there are a supposedly single path of code generation but it is impossible to maintain with a lot of duplication where there shouldn't be. We should get this cleaned up and have a more structured scaffolding system in quarkus that extensions can provide.

We've so far identified following "stages" of scaffold generation:

[ ] Initial scaffold - when extension added to a project (possibly created at the same time), toolchain checks if “example” available and apply to project if user chosen to include examples. Idea is that these are all narrow and independent scaffolding so no overlaps. Example code that gets added to the getting started project based on which extensions are selected (via code.quarkus.io, maven, etc). For example, select “Hibernate ORM with Panache” and an example Panache Entity is added to the code.
[ ] Continous scaffolding - these are tasks like add-entity, add-controller, etc. that "competes" with jhipster and similar. Concerns that we'll end up with lot of duplication and it might be better to just enable these frameworks to integrate with us better ?
[ ] Continous scaffolding from external service - similar to the past but where they are code-first approaches; these are data-first/external system first approaches. i.e. reveng-entity, service-generation from open-api, compose services.
[ ] Service "linking" - this is the kind of scaffolding where quarkus might have a lot of the info needed to easily link up a database in a kubernetes cluster or setup a kafka queue.

Analysis

challenges - users will be using different build systems (maven/gradle) with different variatns (gradle DSL, kotlin DSL, etc.) and code could be java, scala, kotlin or more in future.

Tasks

[ ] do POC of initial scaffold extensions using launcher Generator framework to use in "initial" framework
[ ] based on POC explore what other of the phases (if any) we would explore.

quintesse commented 4 years ago

Right now I've been working on extracting the Creator part of the Launcher project to make it possible to use it as a stand-alone "library" for generating code.

The Creator works by "merging" code templates together to form a single full-functioning project.

The version of the Creator that was included in the Launcher was already able to generate projects for different languages and framework. It also had a library of different building blocks to choose from, so it was already a pretty generic project.

Still it was built with the Launcher in mind so even though the idea was to make it very generic it still has a lot of "Launcher-isms" which are the things I'm getting rid of right now.

The idea is to create a version of the Creator that's completely generic so it can still be used for the Launcher but also for generating Quarkus projects.

The "only" thing that's necessary for this is to make the library of components completely user-definable. The Creator would then be nothing more than the engine that applies the components to create a project.

emmanuelbernard commented 4 years ago

@maxandersen let's see if we want that in the next 3 to 6 months

maxandersen commented 4 years ago

@quintesse did Creator become useful on its own in meantime ?

evacchi commented 4 years ago

I am interested in this as what we are doing in Kogito may fit well. we generate endpoints automatically from user resource assets but we want to allow customization.

emmanuelbernard commented 4 years ago

@evacchi interesting. This issue is about the initial project generation. Not an ongoing scaffolding (if I recall). You would need the later I suppose for your use case.

maxandersen commented 4 years ago

@evacchi I saw your blog on https://evacchi.github.io/compilers/kogito/2020/04/23/kogito-codegen-design.html on this and yours are in the category of "Continous scaffolding" / "Continous scaffolding with external service"

We do have thoughts on enabling that by extensions and make that a proper okey thing for extensions to do (we kinda already do it with kubernetes-extension but that is for target/*.yaml resources and we pick up if user provide other yaml in src).

If you got ideas on some semantics/apis we can apply in this area do tell as it can get messy quickly.

evacchi commented 4 years ago

@maxandersen @emmanuelbernard I would definitely love to share some thoughts together. Maybe we could come up with a joint proposal for the mechanism to adopt. Sorry for hijacking the thread, I lacked some context. We may continue on the ML :)

quarkusio / quarkus