Hi all https://bz.apache.org/bugzilla/show_bug.cgi?id=61269 is not exactly a new issue but I completely forgot about it until Elliotte Rusty Harold asked about its state yesterday.
The issue is "Ant should support reproducible builds" where the request is more general than "Ant's own build should be reproducible". For a definition of reproducible builds and the things that need to be done, see https://reproducible-builds.org/docs/ For example this defines a SOURCE_DATE_EPOCH environment variable for a deterministic timestamp of the build output. <tstamp> already support this. Given the nature of Ant builds I don't beliieve we can magically make arbitrary build processes reproducible but IMHO it would be a good idea to enable people to do so and not make it more difficult. Some things are already possible today like <zip>'s modificationtime attribute that ensures there the resulting archive does not depend on file times (I believe it still depends on filesystem traversal order right now). Ant could even go further and - in the example above - could implicitly set <zip>'s modificationtime to the value of SOURCE_DATE_EPOCH if the attribute was not set and the environment variable present. In a similar way we could use default values for other things (locale in javadoc is something the Debian folks set, for example) if the variable is present - using it as a signal for "this build should be reproducible". If we agree making reproducible builds via Ant easier, then I thought if we tried to make our own build reproducible we might stumble over places where we make things more difficult than they should be. Also I know the Tomcat community is creating reproducible builds of Tomcat so we could (a) learn from them and (b) ask them which things could be easier. If this is something we consider a goal, then I'd focus my (unfortunately little) spare time on this. I still have "creating SBOMs" on my TODO list but believe these would benefit from reproducible artifacts so would prefer to start there. If you want to stop me from going ahead, please yell. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
