ide Command to automatically create the project structure for a Quarkus application

As a developer and devonfw-ide user, I would like a command/tool that automatically creates the project structure for my Quarkus application for me so that I don't have to do this manually.

At the moment there is no devon command to create a Quarkus application inside devonfw-ide. You have to use the Quarkus Maven plugin or the code generator to create a stub for the application. It would be helpful to have some command (e.g. devon quarkus init), that also creates the files/folder described in the modern project structure guide and the Java package structure after this stub was created. For the packages, the command could ask for the required components and then create the appropriate packages for each component.

Below a first draft of how the command could be implemented. Maybe this would also be a feature for CobiGen, then the corresponding entities for the components could also be generated.

first draft of the command

#!/usr/bin/env bash
if [ -n "${DEVO@N_IDE_TRACE}" ]; then set -vx; fi
# shellcheck source=scripts/functions
source "$(dirname "${0}")"/../functions

function doInit() {
  if [ ! -f "pom.xml" ]
  then
    doFail "You are not in the root directory of a Quarkus project. Navigate to the root directory of the project where the pom.xml file is located and run the command again."
  else 
    if [[ -d "src" ]]
    then
      doCreateProjectStructure "src"
    elif [[ ${1} && -d "${1}/src" ]]
    then
      local src_dir="${1}/src"
      shift
      doCreateProjectStructure "$src_dir"
    else
      doFail "No src directory found!"
    fi
  fi
  exit ${?}
}

function doCreateProjectStructure() {
  local src_directory="$1"
  shift
  cd "$src_directory"
  if [ ! -d "main/docker" ]; then
    mkdir -p "main/docker"
  fi
  if [ ! -d "main/helm" ]; then
    mkdir -p "main/helm"
  fi
  if [ ! -d "main/java" ]; then
    mkdir -p "main/java"
  fi
  if [ ! -d "main/resources" ]; then
    mkdir -p "main/resources"
  fi
  if [ ! -d "test/java" ]; then
    mkdir -p "test/java"
  fi
  if [ ! -d "test/resources" ]; then
    mkdir -p "test/resources"
  fi
  doCreateJavaPackageStructure "main/java"
}

function doCreateJavaPackageStructure() {
  local src_directory="$1"
  shift
  cd "$src_directory"
  read -r -p "Name of the base package (e.g. com.devonfw): " base_package
  if [ ! -z $base_package ]
  then
    local base_package_path=${base_package//.//}
    local packages=("general.domain.model")
    read -r -p "List of components separated by spaces (product -> productmanagement): " -a components
    for component in ${components[@]}
    do
      packages+=("${component}management.domain.repo")
      packages+=("${component}management.domain.model")
      packages+=("${component}management.logic")
      packages+=("${component}management.service.v1.mapper")
      packages+=("${component}management.service.v1.model")
    done
    for package in ${packages[@]}
    do
      if [ ! -d "$base_package_path/${package//.//}" ]
      then
        mkdir -p "$base_package_path/${package//.//}"
        echo "created $base_package_path/${package//.//}"
      else
        echo "package $base_package_path/${package//.//} already exists"
      fi
    done
  fi
  exit ${?}
}

# CLI
if [ "${1}" = "-i" ] || [ "${1}" = "init" ]
then
  shift
  doInit "${@}"
else
  doFail "Unknown argument ${1}"
fi

Oct 13 '21 11:10 GuentherJulian

First discussion with @maybeec: It would be better to adapt the devon java create command regarding Quarkus application creation. For example add a option to switch between Spring and Quarkus. If the user selects Quarkus, provide an option to select and create a application based on our recommendations. Alternatively provide an option to manually enter an own URL for the code generator. Then download and unzip the project automatically.

Oct 13 '21 12:10 GuentherJulian

I am a little puzzeled here on how to proceed: In my review of PR #645 I discovered that we code some "post-processing logic" on top of the quarkus template to align the result to our devon4j expectations. I have quite some concerns simulating a "java refactoring" of a template from quarkus (not maintained by us) hardcoded in bash scripts inside a devonfw-ide release.

How should we proceed?

KISS: stay with the vanilla quarkus template and avoid/remove such "post-processing logic".
Create a maven archetype project inside https://github.com/devonfw/devon4quarkus/ that only contains the minimal structure we want to have specific for devon. Then we can instantiate this archetype and extract the quarkus template on top of it. This gives us maintainability and devonfw-ide could always use the latest released archetype so if we need to change something, we do not need an extra devonfw-ide release for it.
keep as is (unmaintainable hack?)
other ideas?

Apr 05 '22 08:04 hohwille

Hi @hohwille, the general idea was to gain benefit from the existing code.quarkus.io generator in combination with pushing our naming conventions on top. The problem we had in the discussion was, that given the case you are setting up an archetype, what dependencies would you ship already? In a more scattered microservices world different services come with very different requirements on the maven dependencies.

Thus, providing a very minimal archetype, next question would again automatically be raised, why should I start with the devonfw archetype? - Therefore, we basically approached the idea to do very basic and generic refactorings of the sample code, which is generated by the quarkus project generator, to gain most of both worlds. My view on that was basically, that we should do a best effort approach to make code look as near as possible to what we approach with the modern architecture guidelines.

During the discussions we came to the conclusion that archetypes could be beneficial, if we eventually provide a proper categorization of different types microservices which would imply a certain set of technology choices defaulted by devonfw proposals. That's also how it is done in projects like the project of @yntelectual. They have archetypes for specific purpose microservices. I feel that makes sense, but one-for-all, doesn't provide any value. @LarsReinken will start his thesis on this topic from a general point of view, which might give some inputs like a list types and even their technical requirements. He will also conduct some interviews to gain experiences from projects as well as to see what research is doing here. This might be a valuable input to think about archetypes.

My suggestion therefore, is to continue with the automatic naming convention application in a resilient way (choose proper defaults) to at least gain all from the code generator of quarkus.io and let it comply as best as possible to what we propose as naming conventions.

Apr 11 '22 08:04 maybeec

Hi together, what about not having any automation here? My personal view on this would be a quick Quarkus setup guide (max 1 A4 page) Download quarkus with the dependencies you need from the quarkus generator. Create the package structure inside (link to the project structure guide). And then next steps Links to further guidance:

You need a database
Security (Authorization, Authentication, CSRF, CORS) (The user can decide what he needs)
Service layer (REST, gRPC, SOAP, Kafka,...)

For me this should get more into this self service portal. As Malte mentioned I think there'll be no one fits all solution. For me devonfw is a blue print with different building blocks the user can choose from. We should enable him to do so by himself.

Apr 14 '22 11:04 baumeister25