lhotari opened a new pull request, #25841:
URL: https://github.com/apache/pulsar/pull/25841
### Motivation
The previous `generatePulsarVersion` task in `pulsar-common` substituted
git/build metadata
into a **Java source file**
(`build/generated-sources/java-templates/.../PulsarVersion.java`)
on the compile source path. Whenever the task re-ran (e.g. after `clean`, a
version bump, or
template change) the regenerated `.java` differed in content, which
invalidated
`pulsar-common:compileJava` and cascaded to every downstream `compileJava`
task. To soften
this, the task previously chose **not** to declare git inputs (see the TODO
comment in the
old build script), trading accurate metadata for fewer rebuilds.
### Modifications
- Convert `pulsar-common/src/main/java/org/apache/pulsar/PulsarVersion.java`
from a Gradle
template into a regular Java class that loads its values from
`/org/apache/pulsar/pulsar-version.properties` on the classpath. When the
resource is
missing (or a given key is empty), the getters return the literal
`"unknown"`.
- Replace `generatePulsarVersion` with `generatePulsarBuildInfo` in
`pulsar-common/build.gradle.kts`. The task now writes a *resource* under
`build/generated-resources/buildinfo/org/apache/pulsar/pulsar-version.properties`
and
registers that directory as a `sourceSets["main"].resources.srcDir(...)`.
Because
resources are not on the Java compile classpath of downstream modules,
regenerating the
properties file only re-runs `pulsar-common:processResources` / `:jar`;
every
`compileJava` (including downstream consumers like `pulsar-broker`) stays
UP-TO-DATE.
- Add a `pulsar.includeBuildInfo` Gradle property, defaulting to `false` in
`gradle.properties` so day-to-day development doesn't regenerate the file.
Release
builds must enable it via `-Ppulsar.includeBuildInfo=true` on the command
line, or set
`pulsar.includeBuildInfo=true` in `~/.gradle/gradle.properties` before
running the
release. When disabled, the properties file only contains `version=…` and
the runtime
getters return `"unknown"` for git/build metadata.
- Update `.github/actions/setup-gradle/action.yml` to append
`pulsar.includeBuildInfo=true` to `~/.gradle/gradle.properties` after
Gradle is set up,
so CI builds (which produce the artifacts users consume) always embed real
metadata.
- The `git rev-parse` / `git config` calls are wrapped in lazy
`providers.exec { ... }`
consumed inside `doLast`, so they never become configuration-cache inputs.
The output
file uses a hand-rolled `.properties` writer to avoid the
non-deterministic timestamp
comment that `Properties.store(...)` always emits.
- Add `pulsar-common/src/main/java/org/apache/pulsar/package-info.java`
(required by
checkstyle now that `PulsarVersion` lives under `src/main/java/`).
### Verifying this change
- [ ] Make sure that the change passes the CI checks.
This change is already covered by existing tests, such as
`AddMissingPatchVersionTest`
(the `fixVersionString` helper is unchanged). Behavioral verification done
locally:
- `./gradlew :pulsar-broker:compileJava --configuration-cache` is run twice
with the
working tree made dirty in between: both invocations report all
`compileJava` tasks
UP-TO-DATE and `Configuration cache entry reused`.
- Forcing regeneration of `pulsar-version.properties` (by deleting it)
re-runs only
`generatePulsarBuildInfo` and `processResources`; no downstream
`compileJava` runs.
- `./gradlew :pulsar-client-shaded:shadowJar` produces a jar containing both
`org/apache/pulsar/PulsarVersion.class` and
`org/apache/pulsar/pulsar-version.properties`.
- A standalone run of `PulsarVersion` getters returns the real values when
the properties
resource is on the classpath, and `"unknown"` placeholders when it is not.
- `./gradlew :pulsar-common:build -x test` passes (spotless, checkstyle,
jar, …) under
the new layout.
### Does this pull request potentially affect one of the following parts:
- [x] Anything that affects deployment — release / distribution builds
**must** pass
`-Ppulsar.includeBuildInfo=true` (or set it in
`~/.gradle/gradle.properties`) to
embed git commit / branch / build host / build time in the published
jars. CI builds
already get this automatically via the updated `setup-gradle`
composite action. If
a release pipeline reproduces a build outside of GitHub Actions, the
operator needs
to set the property explicitly.
### Documentation
- [x] `doc-not-needed`
--
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]
