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.
https://github.com/devonfw/devon4j/blob/3c38fa5ad72658829ea063b2ad32a14ba8604d7e/modules/rest/src/main/java/com/devonfw/module/rest/service/impl/RestServiceExceptionFacade.java#L133
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.
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.
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-utilinto many smaller modules a long time ago. We had removed the dependencies from entities so they do not depend onmmmanymore. However, the decoupling ofmmmhas 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. https://github.com/devonfw/devon4j/blob/3c38fa5ad72658829ea063b2ad32a14ba8604d7e/modules/rest/src/main/java/com/devonfw/module/rest/service/impl/RestServiceExceptionFacade.java#L133 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
RestServiceExceptionFacadefrom our module to the app template.2. https://github.com/devonfw/devon4j/blob/3c38fa5ad72658829ea063b2ad32a14ba8604d7e/modules/cxf-client/pom.xml#L32 Can IMHO be removed without impact if next issue is addressed.
3. https://github.com/devonfw/devon4j/blob/3c38fa5ad72658829ea063b2ad32a14ba8604d7e/modules/service/src/main/java/com/devonfw/module/service/common/impl/client/ServiceClientErrorFactoryImpl.java#L30 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.
https://github.com/devonfw/devon4j/blob/3c38fa5ad72658829ea063b2ad32a14ba8604d7e/modules/http-client/pom.xml#L31 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.