gitgabrio opened a new pull request, #6633: URL: https://github.com/apache/incubator-kie-drools/pull/6633
Fixes: https://github.com/apache/incubator-kie-issues/issues/2029 Needed by: https://github.com/apache/incubator-kie-kogito-runtimes/pull/4220 https://github.com/apache/incubator-kie-kogito-apps/pull/2308 https://github.com/apache/incubator-kie-kogito-examples/pull/2196 ** Please read ticket description to understand the motivation behind this PR ** Please consider that the motivation of this PR rely on the unitary view of all our codestack (from drools to examples to kie tools) and not on specific considerations of repositories/modules considered by themselves in isolation. This PR: 1. move all the `dependencyManagement`(s) tags to the `drools-build-parent` pom 2. remove all the `dependencyManagement`(s) tags from all other poms 3. create a `kie-quarkus-build-parent`specific bom that extend `drools-build-parent` one 4. modify the `drools-quarkus-extension` pom to inherit from `kie-quarkus-build-parent` 5. implement a custom enforcer rule `noDependencyManagementRule` to "forbid" declaration of `dependencyManagement` tag in module, not even inside `profile`(s) (it could be overridden, though: see later) The `kie-quarkus-build-parent` _extends_ the `drools-build-parent` one, instead of importing it, to also inherit the `plugingManagement`. It declares the `<allowedPomsList>org.kie:kie-quarkus-build-parent</allowedPomsList>` property to not fail on the `noDependencyManagementRule` check. The reason for the `noDependencyManagementRule` is to avoid/limit the habitual approach of adding `dependencyManagement` in downstream/leaf modules. The problem to solve is that, in our code base, we have multiple versions inconsistency due to the fact that: 1. the same dependency is declared, with different versions, in "parent" and "children" modules 2. the same dependency is inherited transitively on some module but explicit declared in other ones 3. at the very bottom of the stack (i.e. final applications/examples) there are multiple convergence issues due to the above 4. the trickiest part is that in most cases the wrong behavior is not at compile time, where it would be easily spotted, but at runtime, maybe in some combination of artifacts/examples that are not even tested in community Those points makes our code base frail and hard to maintain (e.g. long time required for frameworks migrations, with overall delay in community major versions releases) for two reasons: 1. there are situations where it is not clear why there is the version clash 2. whenever there is a request for massive versions upgrade (i.e. quarkus/springboot migration) the modifications have to be done in multiple places and possible failures (when not at compile level) could be hidden <details> <summary> How to replicate CI configuration locally? </summary> Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use [build-chain tool](https://github.com/kiegroup/github-action-build-chain) to handle cross repository builds and be sure that we always use latest version of the code for each repository. [build-chain tool](https://github.com/kiegroup/github-action-build-chain) is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See [local execution](https://github.com/kiegroup/github-action-build-chain#local-execution) details to get more information about it. </details> <details> <summary> How to retest this PR or trigger a specific build: </summary> - for <b>pull request and downstream checks</b> - Push a new commit to the PR. An empty commit would be enough. - for a <b>full downstream build</b> - for <b>github actions</b> job: add the label `run_fdb` - for <b>Jenkins PR check only</b> - If you are an ASF committer for KIE podling, login to Jenkins (https://ci-builds.apache.org/job/KIE/job/drools/), go to the specific PR job, and click on `Build Now` button. </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
