-
Bug
-
Resolution: Done
-
Critical
-
None
-
None
There is a kogito-bom for user projects to import:
https://mvnrepository.com/artifact/org.kie.kogito/kogito-bom/0.11.1
Unfortunately, it's not a "user bom". It's a "platform bom", because it also contains declarations for ch.qos.logback, com.thoughtworks.xstream and many other non-org.kie.kogito artifacts. In practice, that makes it unusable for users.
A "user bom" only contains dependencies from the same groupId. It can co-exist with users boms from other projects, such as the junit-bom, hibernate-bom, optaplanner-bom, etc. If both junit and optaplanner use logback, they won't override the logback version of each other and let transitive dependency rules and conflict resolution play it's part.
A "platform bom" contains all dependencies for a platform. Quarkus is a platform. Spring is a platform. They are the glue that integrates the rest of the libraries together. They are the dominant bom. Kogito, OptaPlanner, Logback, XStream, Hibernate, ... we aren't platforms, we need to align with the platforms. Any attempt to be the platform, frictions with the Quarkus/Spring platforms. The eternal struggle to keep our dependency versions aligned with Quarkus/Spring, only gets worse: with a user-bom, our dependency versions must not be higher, with a platform-bom, our dependency versions must not be higher nor lower: they must exactly match. This implies that kogito-bom gives up the freedom to both be compatible with 2 sequential quarkus/spring versions (for example quarkus 1.5 and 1.6).
Proposal A)
Do nothing
Proposal B)
Introduce kogito-user-bom (not recommended, as a user bom's expected name would simply be kogito-bom) It duplicates all the metadata from kogito-parent, but it can't extend it. Not maintenance friendly.
Proposal C) // RECOMMENDED
Split up kogito-parent into:
- kogito-parent which contains metadata (url, license, ...)
- kogito-build-parent which contains dependencies and extends kogito-parent
Keep kogito-bom that extends kogito-parent, it will no longer inherit all dependencies.
Reroute all modules, for example kogito-drools to extend kogito-build-parent and use <relativePath> to connect it.
Geoffrey De Smet: Quarkus and optaplanner master use the approach in proposal C). Kie 7 used to do something similar.
- causes
-
KOGITO-3309 kogito-bom must not define version properties of 3rd party artifacts
- Closed