I can build a zipped version of gradle from source using a command line;
gradlew -Prelease=true -Prelease.scope=major -Prelease.stage=final :distribution-full:binDistributionZip -PfinalRelease
However, I noticed that all the files that are in the ZIP file contain an EPOC date of Feb 1 1980. I would prefer the actual timestamp of the file creation date. What parameter do I need to add to my command line build to achieve this?
Since Gradle 9.0.0 build archives are configured to be reproducible by default: Upgrading to Gradle 9.0.0
Gradle is using itself to build.
So I guess you would need to do the mentioned settings for the archive tasks where you want that. I doubt there is a ready-made flag for it, though I don’t know.
Greetings and thanx for reply,
My goal is to build gradle from the source code so that I can at some point become a helper/contributor. I figured the best way is to become familiar with build process and how stuff works. SO, building from scratch will afford me opportunities to learn. ANy help greatly appreciated.
regards,
joe
But why would you want to build differently than the actual release is built?
I dont. I want to be able to make modifications, like fixing bugs, then for my edification, build release. The goal is to build exactly as the official release is built.
But then your question here is moot, isn’t it?
Or what makes you think the official release does not have the reproducible timestamp?
Besides that for testing contributions, you don’t really need to build the final distribution file.
This is all a learning process. I can build a final release now as I described. My finalRelease has no timestamp as its a finalRelease. Again my question is; The files contained inside the zip are all EPOC dated. Is it a bug or by design? I wanna learn. Is it a secret how it is supposed to work? If so, then that is another facet.
Why a secret all is open source and I also shared the information already?
As I said and linked to above, since Gradle 9.0.0 archives you build are by default reproducible which includes uniform timestamps which is an intended change, not a bug.
Gradle is built using Gradle, so is affected the same.
And I doubt there is a central setting to change it in the Gradle build, but just read it, you have the sources.
Also, just get the official release and check whether there it is the same or different, then you know exactly whether it is like there.
IM sorry but you really havnt answered my question. Look at my initial question. Just for the purposes of explanation; what if I was –offline in a network that was airlock. NO internet connectivity and I want to build from the source code. I have the tools, i.e. gradlew from prior version and the source. Is your response the same?
IM sorry but you really havnt answered my question. Look at my initial question.
Mind elaborating on what is still unclear?
Just for the purposes of explanation; what if I was –offline in a network that was airlock. NO internet connectivity and I want to build from the source code. I have the tools, i.e. gradlew from prior version and the source. Is your response the same?
Why should my answer differ? What has building offline to do with the timestamps?
I think you are inferring that I am talking about a snapshot build where the zip file and the internal file names contain the snapshot timestamp. My question is referring to the operating system date that is on the included files; example- -rw-rw-r–. 1 username group 976 Feb 1 1980 README
I think you are inferring that I am talking about a snapshot build where the zip file and the internal file names contain the snapshot timestamp.
No, I am not
My question is referring to the operating system date that is on the included files; example- -rw-rw-r–. 1 username group 976 Feb 1 1980 README
Yes, I know exactly what you talk about.