Closed matus-m closed 2 years ago
@hohwille what do you think is the best solution for the code we have in the general
package right now (like ApplicationPersistenceEntity
) and used across multiple projects. Since we removed the tkit libraries from the reference project, I think it would be best to have a devonfw specific solution.
We have contradicting requirements here.
However, most of our users want to have exactly the opposite:
They do not want a devonfw as framework that makes them dependent on external code that they can not easily adopt and control. Therefore we went for the approach to put some common code in this general package.
The idea is that CobiGen can generate all the required code into your project automatically if you want to add a specific feature. However, you always have the freedom to change and adapt that code to your own requirements (may it be adding some extra logging, changing the mapping of your primary-keys, etc.
We had serious complaints from users when we had put things like ApplicationPersistenceEntity
into a "locked" library from devonfw.
I therefore tend to close this issue as rejected. However, I leave it open for a while for further discussion in case there is more feedback or disagreement on my point of view.
Closing after stale for long.
The reference project contains
Additionally we still have
general
top level package, that contains some code that should not be in a reference project - either it should come from 1000kit-quarkus libs, or some existing devon lib if exists. There is a PR open that removes most of it - but AbstractEntity still stays.UC
classes and their impl classes which look totally out of place in a lean, cloud native project .The usage of Spring data, and Query DSL should also be documented - if that is the Devon recommended approach.