chrisrueger commented on PR #103: URL: https://github.com/apache/freemarker/pull/103#issuecomment-1869118133
> > What do I need to do, to build so the version is `2.3.33` without qualifiers? > > `version.properties` itself is the source of the version number. Before a release, we just modify it to have `version=2.3.33` (and the other similiar version properties there), and commit it. But see the comments in `version.properties`. So, we have to remove `buildTimestamp=...`, but everything else can stay. Ok thanks. I discovered one problem: The tokens like `nightly_@timestampInVersion@` in comments of `version.properties` were replaced too (I think in [FreemarkerRootPlugin](https://github.com/apache/freemarker/blob/2.3-gae/buildSrc/src/main/kotlin/freemarker/build/FreemarkerRootPlugin.kt#L67C56-L67C56) ). I think that this can easily be forgotten during a release. Thus I changed the comment in 9677cda slightly to `nightly_[timestampInVersion]` (square brackets `[]` instead of `@@`). That way during a release you only have to adjust the real properties `version`, `mavenVersion`, `versionForOSGi` and do not care about the comments. If you know a better solution to avoid the replacement in comments, I'm glad to know. Few more words to my latest 3 commits: c9aa766978359232410aabb8808c3b1e2faa182a : I decided to NOT remove the `buildTimestamp` for now, because removal made some testcases fail and the buildtimestamp is also referenced in code (Version.java). I wanted to avoid too many changes for this PR here for now, before having a discussion about it. So for now buildtimestamp is a fixed value now (`buildTimestamp=1980-02-01T00:00:00Z`). So it is rather meaningless, but at least backwards-compatible for the current code. 17ee92ca2f6dee2a6c59954d94e55ba1ad5fc11b and 5bcc56f18bbd675a042b16c2947bddf9891a0c6f: here I think I fixed the problem related to executability of `gradlew` which you pointed out. > `gradlew`: I meant, it's not executable in the source distribution tar. > `tar -tvf apache-freemarker-gae-src-2.3.33-SNAPSHOT.tgz` gives `-rw-r--r-- 0/0 8941 1970-01-02 01:00 gradlew`. > But I just realized that that's already broken in the `2.3-gae` branch. But I guess if I fix that these, the `filePermissions { unix("rw-r--r--") }` you added will collide with that. I just applied the permissions and reproducible attributes (file timestamps, ordering) to the contents of the .jar files e.g. in `build/libs` like `freemarker-gae-2.3.33-sources.jar `, `freemarker-gae-2.3.33-javadoc.jar`, `freemarker-gae-2.3.33.jar`. IMO these three files are what's need to be reproducible. > > > You mean more specific to "what exact Java version (incl. build) to use and to do to get the exact same build result"? > > Yes. Like is it Oracle, is it OpenJDK, etc., and then which build exactly. I assume we have to specify that, and from there, the JDK will be pretty much always downloaded at first build (because the user doesn't have exactly the same version). > Hmm regarding exact vendor and version. I did a little more investigation. In short: I have not really found out yet how to specify this in such detail. It looks like `foo-jay` works based on gradle toolchain definitions: see https://github.com/gradle/foojay-toolchains?tab=readme-ov-file#matching-toolchain-specifications I found that you could specify the vendor. I also checked a few .buildspec of the reproducible central guys files e.g. https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/opentelemetry/instrumentation/opentelemetry-1.14.0-alpha.buildspec which mostly define jdk=11, jdk=17 and the like. Less often I have found more specific definition like jdk=17.0.3. but no vendor like Oracle, Temurin. The guide e.g. https://maven.apache.org/guides/mini/guide-reproducible-builds.html mentions: > Generally depend on the major version of the JDK used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode) And I have the feeling that this is the way it is treated. The `.buildinfo` file ([see here](https://reproducible-builds.org/docs/jvm/#buildinfo-file)) seems to contain more details, but it seems to be just for documentation how a build has been created... (used to lookup by humans not by tools). `After 3 years of work on Reproducible Builds, it has been found more useful as an internal file format: Reproducible Central and its .buildspec format is more what we need to check that Reproducible Builds results has been achieved. .buildinfo just records a build, be it reproducible or not. ` So I don't really know how to proceed. My gut feeling is that we could keep it like it is now. We could just explain e.g. in the README which JDK you need for a reproducible build (and make a recommendation) and then it is up to the developer bringing it's machine to this state. We could provide ``` plugins { id("org.gradle.toolchains.foojay-resolver-convention") version "0.7.0" } ``` to make it easier to build right away, but document in the README that for a reproducible build a specific JDK is required. > > How do you create this `apache-freemarker-gae-src-2.3.33-SNAPSHOT.tgz`? I like to try it out. > > `gradlew build`, and then see in `build/distributions`. Oh, so simple.. Thanks :) One thing I could not test: When I adjusted `version.properties` to `2.3.33` to simulate a release, `gradlew clean build` and `gradlew clean check` failed with ``` Execution failed for task ':verifyReleaseSetup'. > Package signing is disabled! ``` Only `gradlew clean jar` worked. So I just verified the freemarker.jar in `build/libs/freemarker-gae-2.3.33.jar`. Maybe you could try it since I guess you have this `package signing` enabled -- 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]
