Core-Common dependency management optimization
Issue: Core-Common dependency management optimization
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context
The role of the Core-Common Library is to provide common models used in OSDU APIs, common interfaces for interservice communication, and reusable utilities, so to say it is a domain library. It is not used as a dependency management control center, as all dependency management happens at the OSDU services root POM level. Core-Common contains high-level dependencies such as Spring Boot.
Problem Statement
The dependency management of the Core-Common library is misused, as it contains high-level frameworks that are unnecessary for the library itself as library consumers define those frameworks in their POM files.
Assigning the role of dependency manager to Core-Common is also meaningless, as its lifecycle diverges from OSDU services. Vulnerability fixes are prioritized for services rather than libraries, forcing developers to fix service dependencies first. When updates come to the library, services are usually already upgraded via a set of exclusions and overrides.
In the end, the library serves more as a source of dependency conflicts, slowing down major migrations and vulnerability fixes.
Decision
Align the actual responsibilities of Core-Common with its dependency management. Replace heavy dependencies with shallow versions if available: spring-boot should be replaced by spring-context, etc.
Otherwise, change the scope to provided. Thus the consumers won't have to override the dependency versions from Core-Common as it happens now.
Consequences
Core-Common will become more of a shallow dependency, providing common models and interfaces as intended. This will result in fewer conflicts during dependency upgrades and potentially make it usable in Java services that do not rely on Spring Boot.
Some projects may have to declare dependencies explicitly.
Appendices
Core-Common will still contain many framework-specific configurations, such as Spring Context configurations, making it not a clear domain-purposed library. However, addressing this issue is currently out of scope as we do not have a necessity to decouple those configurations.