BOM-Policy in A12

General
1

Peace,

we implement a way to utilize BOMs more explicitly, for avoiding errors like here → Workflows Xerces and Hazelcast don't like each other

Besides the Spring BOM, we saw that multiple A12 projects providing a BOM too. Uaa and Kernel just providing versions for their own artifacts and no 3rd party libraries.
Dataservices provides versions for 3rd party libraries, like jakarta.validation-api or xmlunit-assertj which would overwrite the from the Spring BOM defined one which is fine from our perspective.

My question is, if we can rely on this fact, that Dataservices is providing 3rd party libraries only ? Because when another project will also provide these and they share a subset, then it can be confuse and lead to an error, when this subset contains different versions for the same artifact.

Happy regards,
Tjorben

2

Hi @tgschwander ,

Data Services provides only versions of dependencies that they use. So it could happen that you’ll use other libraries from UAA that Data Services do not use and then you must specify all missing dependency versions.

But we strictly recommend not overwrite versions from Data Services BOM, because they are tailored for the proper application run and it’s tested with them.