Skip to content

Consider removing mmm dependencies #562

@hohwille

Description

@hohwille

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.

<artifactId>mmm-util-exception</artifactId>

Can IMHO be removed without impact if next issue is addressed.

return new ServiceInvocationFailedException(cause, message, code, uuid, service);

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.

<artifactId>mmm-util-exception</artifactId>

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions