local output timestamp for Reproducible Builds

[hboutemy]

No description provided.

[hazendaz]

@hboutemy This was added through our parent pom, is it necessary to add it to every single other pom?

[hboutemy]

@hazendaz it is not absolutely necessary: your build inherits value from parent. This is for example the case for mybatis-guice: https://github.com/jvm-repo-rebuild/reproducible-central#org.mybatis:mybatis-guice

but the timestamp is the value of your parent release, not the timestamp of the current release: if you don't care, you can ignore this little addition. If you do care of the timestamp in you jar files, this local property will provide what people in general prefer: the timestamp is the timestamp of the release

[hazendaz]

@hboutemy Ok I get that and see internals built now show 2/17 when the parent was released. I manually applied locally as this leads me to a separate question. With that set same as parent, it still gets 2/17. I further noticed on spring boot apps those will redate the file to the parent date of release. So in a case where I simply build locally and lets say it never releases through central/artifactory or other, what is expected to ensure the date is correct? I should mean to say, we don't run it through a maven release cycle. Is manually updating it with full date the appropriate way then? Or does that '1' cause that?

[hazendaz]

I'm testing with a 1 now to see what happens out of curiousity.

[hazendaz]

@hboutemy ok so using 1 ends up with no timestamps in the files. Is there a better way to do this for builds that do not release using maven? In that particular case, something that would just list it at the date currently built seems most applicable. I guess no timestamps in that case will work from a reproducable standpoint but may be odd.

[hboutemy]

maven-release-plugin will do the updates when necessary
during SNAPSHOT, reproduciblity is less a question

[hazendaz]

mabe the command that causes that as part of release. we are looking at adding some auto tagging / merge when code installations are complete so if we go with say "1" at first which we can automate in general to 100s of repos, when those release - even if not maven, we could run whatever command to force the date to update.

[hazendaz]

ok gotcha

[hboutemy]

notice that even with 1, there is still a timestamp: you can't avoid files in a zip file to have a timestamp, it is part of any archive format

[hazendaz]

[hazendaz]

@hboutemy with 1, the modified is blank. With other values, its populated. That was my concern. The file on disk is accurate regardless (except for spring boot which to use that internal date on rebundle).

[coveralls]

Coverage remained the same at 100.0% when pulling c0cd4ba on hboutemy:patch-1 into e7ce648 on mybatis:master.