vinishjail97 commented on code in PR #867:
URL: https://github.com/apache/incubator-xtable/pull/867#discussion_r3660477616
##########
xtable-service/pom.xml:
##########
@@ -250,6 +250,15 @@
</dependencies>
<build>
<plugins>
+ <!--
Review Comment:
Shortened in a227a3e1 — down to four lines plus that link, thanks for the
pointer. It now just says the plugin resolves its own dependencies and needs
`effective-model-builder` to match `xtable-core_${scala.binary.version}`
against the reactor, and that the property lives in `.mvn/maven.config` because
Quarkus only reads it as a system property.
##########
.github/workflows/mvn-ci-build.yml:
##########
@@ -45,3 +45,28 @@ jobs:
- name: Build all module with Maven
run: ./mvnw clean install -ntp -B
+
+ package:
Review Comment:
Fair point, a second full build on every push and PR is too much. Scoped it
down in a227a3e1: the separate job is gone and it is now a step in the existing
build job, limited to `-pl xtable-service -am -DskipTests`, so it only builds
xtable-api, xtable-hudi-support-utils, xtable-core and xtable-service, and
skips the shade modules.
I checked that the narrower reactor still catches the failure. With
`.mvn/maven.config` removed, `./mvnw clean package -pl xtable-service -am
-DskipTests` fails with `xtable-core_2.12:jar:<version> (absent)`; with it in
place the same command succeeds.
The `rm -rf ~/.m2/repository/org/apache/xtable` is the part that makes it
meaningful. `cache: maven` restores a `~/.m2` that the `install` step populated
on an earlier run, and Quarkus falls back to repository resolution, so without
deleting those artifacts the check passes even when the source release is
broken. That is why rc1 built fine for all of us locally.
--
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]
