vinishjail97 opened a new pull request, #868:
URL: https://github.com/apache/incubator-xtable/pull/868
Fixes #864
## What is the purpose of the pull request
This is the `branch-0.4` counterpart of the `main` PR, and it unblocks the
0.4.0 release candidate.
`0.4.0-incubating-rc1` received a -1 because `./mvnw clean package` on the
source release fails in `xtable-service`:
```
Failed to bootstrap application in TEST mode: Failed to resolve dependencies
for
org.apache.xtable:xtable-service:jar:0.4.0-incubating: The following
artifacts could not be
resolved: org.apache.xtable:xtable-core_2.12:jar:0.4.0-incubating (absent),
org.apache.xtable:xtable-core_2.12:jar:tests:0.4.0-incubating (absent)
```
`quarkus-maven-plugin` bootstraps the application to generate code, so it
resolves this module's dependencies with Quarkus' own bootstrap resolver rather
than through the reactor. That resolver discovers the workspace from the raw
poms without interpolating properties, so the module declaring
`xtable-core_${scala.binary.version}` is never matched against the
`xtable-core_2.12` dependency, and resolution falls back to the remote
repositories — where the artifact only exists once the release has been
published. Modules with literal artifactIds (`xtable-api`,
`xtable-hudi-support-utils`) resolve from the reactor fine, which is why the
error names only `xtable-core_2.12`.
Every build path we have runs `mvn install`, which puts `xtable-core` in the
local repository and lets Quarkus' repository fallback succeed. Plain `mvn
package`, what a release validator runs, is the one path never exercised —
hence this reaching a release candidate.
## Brief change log
- Set `-Dquarkus.bootstrap.effective-model-builder=true` in
`.mvn/maven.config` so workspace discovery uses the effective model and
resolves the property. Quarkus reads this only as a JVM system property (a pom
`<properties>` entry has no effect, verified), and `.mvn/` already ships in the
source release tarball.
- Documented the reason above the `quarkus-maven-plugin` declaration in
`xtable-service/pom.xml`, since `maven.config` cannot carry comments.
- Added a `package`-only CI job that first removes locally installed XTable
artifacts, so the reactor is the only place they can come from. Without the
`rm`, `cache: maven` restores a `~/.m2` populated by the `install` job and
hides the failure again.
## Verify this pull request
Verified against the published rc1 source tarball and against this branch,
always with `package` only and with a version that cannot resolve from Maven
Central or from a stale `~/.m2`:
| Build | Result |
| --- | --- |
| rc1 source tarball, `clean package` | fails, reproduces #864 |
| rc1 source tarball + the property as a pom `<properties>` entry | fails —
confirms it must be a system property |
| rc1 source tarball + `.mvn/maven.config` | succeeds |
| this branch as-is | succeeds |
The `main` counterpart is #867.
--
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]
