-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import Spring Boot's dependency BOM, fix spring-boot:run at parent project level #276
Conversation
A little fix when some subproject modules are Spring Boot apps, but the parent is not. Also document how to overcome IntelliJ CE woes with Spring Boot, and inter-module Maven dependencies.
Spring has done the work of finding direct and transitive versions of dependencies compatible with their ecosystem, and declaring them as a BOM. It's in our best interest to heed it as much as we can.
Hi @ches. Thanks for your PR. I'm waiting for a gojek member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Override things *before* here if needed, but be wary of that! | ||
|
||
https://www.baeldung.com/spring-boot-dependency-management-custom-parent | ||
https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left the URL here for convenience outside the IDE, but in IntelliJ you can go-to-definition on the artifactId
below whenever you need to reference what's included.
/ok-to-test |
Per discussion: #271 (comment) The `install` step should not be necessary for the unit tests, but we should use `--batch-mode` on the test step for CI.
/retest |
Confirmed the issue in the end-to-end test, will look into fixing it shortly. |
Thanks! The issue seems to be after packaging the application with
|
It was resulting in a non-functional JAR, appears to be incomplete configuration. It seems unlikely to me that core will be used as a library, if there is a need the shading configuration can be fixed but it probably needs other considerations anyway.
|
Hmm, if the |
Yes it seems so, we need to update it so the end-to-end test is more reproducible. I retry re-run the end-to-end test and it passes now. |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ches, woop The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/pony |
Two things here—can extract out the small fix commit to a separate PR if there's any issue with the (hopefully last for awhile) dependency management-related part.
spring-boot:run
We realized that changing
core
's dependency oningestion
to be inter-module instead of package install-based in #262 left behind a workflow issue. Using something like:from the project root directory broke, because it tried to find a main application class in the parent POM project and failed.
The first commit here resolves that, and provides dev docs whether you prefer to run from the IDE or CLI.
spring-boot-dependencies
A next step for
<dependencyManagement>
. Typically it's recommended that Spring Boot applications inherit thespring-boot-starter-parent
POM, such that you take on its Maven plugin configurations,<dependencyManagement>
section, and<properties>
where dep versions are defined.For a multi-module project that is probably not appropriate, because not every module is a leaf Spring Boot app. Still, it's a good idea to go with composition in lieu of inheritance: import the
<dependencyManagement>
part, via thespring-boot-dependencies
POM. This way you benefit from the application of transitive dependency versions that they've done the work to determine are compatible with the Spring Boot ecosystem, even if left on your own for the plugin configurations.That is done here. All dependencies that are declared as bill of materials by
sprint-boot-dependencies
are removed from being directly declared by us, with exception of a small few that need to be overridden.