Skip to content
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

Merged
merged 4 commits into from
Oct 30, 2019
Merged

Conversation

ches
Copy link
Member

@ches ches commented Oct 28, 2019

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 on ingestion to be inter-module instead of package install-based in #262 left behind a workflow issue. Using something like:

$ mvn -am -pl core spring-boot:run

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 the spring-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 the spring-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.

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.
@feast-ci-bot
Copy link
Collaborator

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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
Copy link
Member Author

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.

@davidheryanto
Copy link
Collaborator

/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.
@ches
Copy link
Member Author

ches commented Oct 29, 2019

/retest

@ches
Copy link
Member Author

ches commented Oct 29, 2019

Confirmed the issue in the end-to-end test, will look into fixing it shortly.

@davidheryanto
Copy link
Collaborator

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 mvn clean package
running java -jar core/target/feast-core-0.3.0-SNAPSHOT.jar throws this error:

Error: Could not find or load main class feast.core.CoreApplication

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.
@ches
Copy link
Member Author

ches commented Oct 30, 2019

maven-shade-plugin usage on core appears to have been the issue, I've removed it completely for now because I can't see core being used as a library as-is, but if there is intention for that that I'm missing let me know and I'll try to fix the configuration instead of removing it.

@ches
Copy link
Member Author

ches commented Oct 30, 2019

Hmm, if the test_basic e2e test failed but test_all_types passed, is that a flaky test, not enough sleep time for the first test that executes maybe? Should I retest?

@davidheryanto
Copy link
Collaborator

Hmm, if the test_basic e2e test failed but test_all_types passed, is that a flaky test, not enough sleep time for the first test that executes maybe? Should I retest?

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.

@davidheryanto
Copy link
Collaborator

/lgtm
Thanks for the fix and cleanup!

@woop
Copy link
Member

woop commented Oct 30, 2019

/approve

@feast-ci-bot
Copy link
Collaborator

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@feast-ci-bot feast-ci-bot merged commit 18d54b7 into feast-dev:0.3-dev Oct 30, 2019
@ches ches deleted the spring-deps-import branch October 30, 2019 07:42
@ches
Copy link
Member Author

ches commented Oct 30, 2019

/pony

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants