Epic: Quarkus Roadmap 2021

[hohwille]

This issue is our epic for the roadmap with quarkus in devonfw for 2021:

Documentation:

• We are in the process of aligning the devon4j documentation and creating 3 areas:
  • general
    with things that are universal for Java and do not differ between stacks such as spring-boot or quarkus. Examples are coding-conventions or dependency-injection.
  • spring
    with the documentation we already have in devon4j that is specific for our current approach with spring-boot. An example is here.
  • quarkus
    for the new documentation parts that are specific for quarkus cloud-native microservices. For separation we will create those in a quarkus subfolder but leave the rest of the existing documentation in place to avoid breaking external links (from publications, articles, blogs, other documentation repos, etc.). This content is currently just evoling and will be migrated from here.
• The backlog can be found via quarkus issues@devon4j.
• issue devon4j#420 is about this documentation restructuring and explains the strategy and rationale behind it. It is linked with Pull-Request(s) that show what we have changed already to align things.
• The changes will automatically step by step appear on our website

Sample:

• We want to have a simple and central reference app using quarkus and devonfw that is evolving in devon4quarkus-reference.
• This app has its own backlog via github issues here
• This reference app will be linked from the quarkus specific documentation
• This app shall work seamless out of the box and show the fundametal features in action.
• Additionally we want to have a second app that has some logic to invoke a service from the refence so we can demonstrate some integration, the REST-client, OpenTelemetry, etc. Most probably we will create a separate repository for it.

Libarary code:

• We are starting with tkit libs that are already available as open source. This allows us to get started quickly.
• Once we have more clearance we can decide to copy and modernize these as devonfw asset what is to be placed in this modules folder of this repository.
• From what we have learned in devonfw is that we should avoid library and framework code where possible. Instead we could also consider to contribute directly to the existing frameworks such as quarkus, etc. where suitable.

CobiGen Templates:

• One of our key accelerators in devonfw is CobiGen
• It can generate code based on templates
• For quarkus we will need slightly adopted templates.
• The templates will in the future go directly into the repositories of the according stacks (currently they are here for devon4j).
• Therefore we will later add those in the templates folder of this repository.
• For CobiGen we also have a big roadmap with language-agnostic templates and many other cool features that will go beyond 2021.
• However, we first have to have all conventions, samples and documentations clear before we can start implementing templates as changes will imply refactoring efforts.

Patterns on integration, orchestration & choreography:

• Most of such patterns (if not all of them) will be independet of the technology and therefore will not go into devon4j or devon4quarkus.
• Instead when we explain patterns like "IAM with keycloak", "service-mesh with istio" or "OpenTelemetry" we can explain this in a way that is independent of the programming language involved for building the microservice. Instead docker, kubernetes, helm, etc. will be our foundation to build such patterns on top.
• Therefore we will keep such patterns as documentation in the architectures repository.
• In case we have a quarkus specific pattern we want to integrate into the new architecture browser, we can do so by putting it into a architecture subfolder inside this documentation folder.

IDE support:

• With devonfw-ide we have a great tool supporting automated setup and update of the local IDE and tooling for developers on their laptops.
• With issue ide#584 we created initial support for docker and kubernetes integration into devonfw-ide that is required for any cloud-native project (quarkus, micronaut, spring-native).
• If we need further support, we can easily integrate more (e.g. create a commandlet for graalvm to invoke the AOT compiler directly on your machine instead of via docker).

Misc:

• The devonfw-microservices repository will dissapear on the long run.