vinishjail97 opened a new pull request, #867:
URL: https://github.com/apache/incubator-xtable/pull/867
Fixes #864
## What is the purpose of the pull request
A source release must build from its own artifact, and right now it does
not. While validating `0.4.0-incubating-rc1`, `./mvnw clean package` on the
extracted source tarball fails in `xtable-service`:
```
Failed to execute goal
io.quarkus.platform:quarkus-maven-plugin:3.2.12.Final:generate-code-tests
(default) on project xtable-service: Quarkus code generation phase has
failed:
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 in order to generate code,
which means it resolves this module's dependencies through Quarkus' own
bootstrap resolver instead of through the reactor. That resolver discovers the
workspace from the raw poms, without interpolating properties, so the module
declaring
```xml
<artifactId>xtable-core_${scala.binary.version}</artifactId>
```
is never matched against the `xtable-core_2.12` dependency. Quarkus then
falls back to the remote repositories, where that artifact only exists once a
release has been published — so the build of an unpublished release fails. The
error names only `xtable-core_2.12`; `xtable-api` and
`xtable-hudi-support-utils` have literal artifactIds and resolve from the
reactor without trouble.
This has been invisible because 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.
## Brief change log
- Set `-Dquarkus.bootstrap.effective-model-builder=true` in
`.mvn/maven.config` so Quarkus' 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
inside the source release tarball, so the setting travels with the release.
- 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. The `rm`
matters: `cache: maven` restores a `~/.m2` that the `install` job has
populated, which would otherwise hide exactly this failure again.
## Verify this pull request
Verified by building with `package` only, in a tree whose version cannot be
resolved 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 + `-Dquarkus.bootstrap.effective-model-builder=true` on
the command line | succeeds |
| rc1 source tarball + `.mvn/maven.config` | succeeds |
| this branch with `.mvn/maven.config` removed | fails |
| this branch as-is | succeeds |
A matching PR targets `branch-0.4`, where this blocks the 0.4.0 release
candidate.
--
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]
