You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have introduced mmm dependencies in devon4j for the following reasons:
entity interfaces and base classes
advanced exception support
NLS/I18N/L10N
The entity stuff caused a strong coupling to a library not world-famous and causing some concerns.
I therefore decoupled things and split mmm-util into many smaller modules a long time ago.
We had removed the dependencies from entities so they do not depend on mmm anymore.
However, the decoupling of mmm has never been completed as those who requested had no more interest in it.
The advanced exception support is nice but in the end it is a matter of more or less one class as shown by the new mmm libs making the NLS optional. We could therefore decide to "copy" that single class into the app template and simply remove all mmm dependencies from the code-base.
The only remaining problems that still have to be solved for this are:
1.
Here we need a common base exception to depend on in order to distinguish between "buisness exceptions" to revel with full error message text to outside and "technical exceptions" that are not revealed due to security (OWASP sensitive data exposure). If we stip out mmm we need to find a different "contract" to make this distinction or we simply also "move" the RestServiceExceptionFacade from our module to the app template.
We could simple create our own exception for this and remove the dependency.
NLS support and features would be lost but most probably they are not needed.
See also issue #449 that I will close and replace by this one.
The biggest problem with this story is that existing projects that want to update to a latest devon4j version then would get the modules without this mmm dependency & coupling and could run into incompatibilities if they are using the mmm-library to define their exceptions and maybe even use its NLS features.
The text was updated successfully, but these errors were encountered:
We have introduced mmm dependencies in devon4j for the following reasons:
The entity stuff caused a strong coupling to a library not world-famous and causing some concerns.
I therefore decoupled things and split
mmm-util
into many smaller modules a long time ago.We had removed the dependencies from entities so they do not depend on
mmm
anymore.However, the decoupling of
mmm
has never been completed as those who requested had no more interest in it.The advanced exception support is nice but in the end it is a matter of more or less one class as shown by the new mmm libs making the NLS optional. We could therefore decide to "copy" that single class into the app template and simply remove all mmm dependencies from the code-base.
The only remaining problems that still have to be solved for this are:
1.
devon4j/modules/rest/src/main/java/com/devonfw/module/rest/service/impl/RestServiceExceptionFacade.java
Line 133 in 3c38fa5
Here we need a common base exception to depend on in order to distinguish between "buisness exceptions" to revel with full error message text to outside and "technical exceptions" that are not revealed due to security (OWASP sensitive data exposure). If we stip out mmm we need to find a different "contract" to make this distinction or we simply also "move" the
RestServiceExceptionFacade
from our module to the app template.devon4j/modules/cxf-client/pom.xml
Line 32 in 3c38fa5
Can IMHO be removed without impact if next issue is addressed.
devon4j/modules/service/src/main/java/com/devonfw/module/service/common/impl/client/ServiceClientErrorFactoryImpl.java
Line 30 in 3c38fa5
We could simple create our own exception for this and remove the dependency.
NLS support and features would be lost but most probably they are not needed.
devon4j/modules/http-client/pom.xml
Line 31 in 3c38fa5
Can IMHO be removed without impact.
See also issue #449 that I will close and replace by this one.
The biggest problem with this story is that existing projects that want to update to a latest devon4j version then would get the modules without this mmm dependency & coupling and could run into incompatibilities if they are using the mmm-library to define their exceptions and maybe even use its NLS features.
The text was updated successfully, but these errors were encountered: