Add a guide in the documentations folder for recommendations on using ORM and JPA in a devon4quarkus application.
https://quarkus.io/guides/hibernate-orm
https://github.com/devonfw/devon4j/blob/master/documentation/guide-jpa.asciidoc

Add a guide in the documentations folder on using asynchronous communication with Apache Kafka in a devon4quarkus application.
https://quarkus.io/guides/kafka
https://github.com/devonfw/devon4j/blob/master/documentation/guide-kafka.asciidoc

Add a guide on how to use spring-data-jpa in a devon4quarkus application. Mention what is working and where are limitations.
devonfw-forge/devonfw-microservices#37

At the moment we use PageImpl as return type in our Rest Services. If we only use the Page interface, serialization will not work in native mode. This is because JSON serialization uses reflection to determine the properties of an object. When using Page, only the interface is registered for reflection by Quarkus, so the other properties needed for paging are not accessible in native mode.

In devon4j there were also issues with serializing Page to/from JSON. The solution in devon4j was to configure Jackson accordingly.
https://github.com/devonfw/devon4j/tree/master/modules/json/src/main/java/com/devonfw/module/json/common/base/type

We need to check if there is also a solution for Quarkus so that we can use Page instead of PageImpl.

Add a guide in the documentations folder on how to create a devon4quarkus application. At the moment, there is no devon command to create such an application. Therefore, describe the Maven commands for creating an application for now. Also mention the Quarkus code generator https://code.quarkus.io/

Create recommendations for selections in the Quarkus code generator and add links with pre-selected extensions for common use cases.

See also this issue devonfw-forge/devonfw-microservices#11

Add a guide in the documentations folder for recommendations on using data access objects (DAOs) in a devon4quarkus application. You can orientate on the devon4j guide https://github.com/devonfw/devon4j/blob/master/documentation/guide-dao.asciidoc

Add a guide in the documentations folder on monitoring of a devon4quarkus application.
https://quarkus.io/guides/smallrye-metrics
https://quarkus.io/guides/micrometer
https://quarkus.io/blog/micrometer-prometheus-openshift/

Add a guide in the documentations folder on bean validation in a devon4quarkus application.
https://quarkus.io/guides/validation

Add a guide in the documentations folder on best practices for logging in a devon4quarkus application.
https://quarkus.io/guides/logging

With devonfw/devon4j#480 a guide with hints on how to migrate a Spring to a Quarkus application is added. Furthermore, it would be very helpful if there were tools that simplify the migration and perform some steps automatically. Red Hat already provides a Migration Toolkit that should help in this topic. With it you can analyze a Spring project and then get hints which dependencies cannot be used for Quarkus and which Quarkus extensions they have to be replaced by. However, nothing is done automatically.
We should evaluate and come up with ideas on how this can be realized. A first start could be to make CobiGen fit for Quarkus, so that CobiGen can create the needed classes, as it is now the case for Spring applications.

Add a guide in the documentations folder on testing of a devon4quarkus application.
https://quarkus.io/guides/getting-started-testing

Add a guide to the overall architecture of a devon4quarkus application in the documentation folder.
You can use the devon4j instructions as a guide https://github.com/devonfw/devon4j/wiki/architecture

Add a guide in the documentations folder for recommendations on naming and structure of the components used in a devon4quarkus application.
https://github.com/devonfw-forge/devonfw-microservices/blob/main/documentation/naming-and-structure.asciidoc

Add a guide in the documentations folder for recommendations on access control aspects used in a devon4quarkus application. The guide should describe aspects of authentication, authorization, JWT and permission handling. You can orientate on the devon4j guide https://github.com/devonfw/devon4j/blob/master/documentation/guide-access-control.asciidoc

Add a guide in the documentations folder for bean mapping in a devon4quarkus application.

Description

There are some packages which don't have much of a usage in the branch with the database support. Test entities were added hence they are rendered useless.
https://github.com/devonfw-sample/devon4quarkus-cicd-testapp-service-b/tree/master-db-support
We would like to remove these packages.

Acceptance Criteria

1. Remove the packages com.devonfw.cicd.testapp.hello.service and com.devonfw.cicd.testapp.hello.logic
2. Make sure they don't impact the project being built successfully

Add a guide in the documentations folder for CORS support in a devon4quarkus application. You can orientate on the devon4j guide. https://github.com/devonfw/devon4j/blob/master/documentation/guide-cors-support.asciidoc

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.