We have feedback from users that want to our devon4j application template (archetype for spring at templates/server) is too complex:
separation of modules (api, core, server) is not needed and adding complexity that is unwanted by many projects
differentiation of packages regarding scope (api, base, impl) is not required anymore (we already simplified this in modern-structure recommended for quarkus, also spring-aop does not require separation of interface and implementation anymore, etc.)
devon4j dependencies are unwanted by some projects. In general the feedback is that we should rather provide samples and blueprint than code released in JAR files. Therefore the fundamental features could be integrated by classes in the control of the devon4j end-user (in his package namespace, generated from app-template) instead of via devon4j specific libraries. This gives the devon4j end-user more freedom and control to customize and tweak such features (example: if you want to get rid of javax.inject and migrate to jakarta.inject you can not change that inside code of java files provided by devonfw team).
if we do so, we can also reduce complexity: e.g. we have created some abstraction and extension mechanism in devon4j modules for flexibility. If we move the features to classes generated by app-template, we can simplify, avoid abstract super-classes, etc.
there are also drawbacks of this approach: currently you can toggle features by just adding a devon4j starter or removing it. However, we assume this is a step in the right direction. However, I will create a draft PR as proposal and then we can discuss about it.
So acceptance criteria is:
[ ] archetype is a single module project
[ ] no devon4j dependencies by default (user can opt-in later what he likes)
[ ] remove scope segment from pacakges
[ ] code reduced/simplified
[ ] archetype is still working (you can create JAX-RS REST-Service that can be directly accessed including JSON/XML mapping, etc., you can create entities working with hibernate, bean-mapping still working including transmission of correct @version, spring-data-repo can be written and works)
Note: On the long run we also want to migrate to JakartaEE. However, this requires spring-boot 3 that will be released in November. So do not expect this to be done before devon4j release 2022.12.001.
We have feedback from users that want to our devon4j application template (archetype for spring at
templates/server) is too complex:api,core,server) is not needed and adding complexity that is unwanted by many projectsapi,base,impl) is not required anymore (we already simplified this in modern-structure recommended for quarkus, also spring-aop does not require separation of interface and implementation anymore, etc.)javax.injectand migrate tojakarta.injectyou can not change that inside code of java files provided by devonfw team).So acceptance criteria is:
Note: On the long run we also want to migrate to JakartaEE. However, this requires spring-boot 3 that will be released in November. So do not expect this to be done before devon4j release
2022.12.001.