ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Bateman <georgebatema...@gmail.com>
Subject Re: Reproducible JARs
Date Wed, 23 Aug 2017 16:28:29 GMT
Hi Gintas and Stefan, and List,

Thanks very much for your emails. Sorry for the slight delay in replying!

On 25 July 2017 at 07:39, Gintautas Grigelionis <g.grigelionis@gmail.com>
wrote:
> I believe the easier way would be to diff the fileset of classes to be
> packed to the fileset of classes in the jar before creating a new jar.
> There's a tool called zipdiff that could do the trick (it may ignore
> timestamps, etc). That would correspond to a javac deciding on whether to
> recompile the classes (which is based on timestamps, I guess ;-).

That doesn't solve the timestamps problem though; two people building from
scratch with no jar or class files to begin with will still get different
modification times in it.

> It sounds to me like you're looking for an equivalent of ClearCase
> winkin. If that's the case, have you read [1]?

I have now, thank you! I'll be honest, adding that sort of capability to
Ant sounds just a little beyond my capabilities. Also, it doesn't seem to
be necessary; javac seems to be giving the same exact output every time for
a given javac version.

Stefan wrote:
> The manifest may contain the current time stamp, to make things worse
> for you :-)

Fortunately, I don't see anywhere in Jar.java that mentions time or date,
except passing it to Zip#zipFile() as the modification time, and I override
it there anyway.

> I'm not sure what you want can be achieved at all. The best you can get
> is the exact same jar when the build has been run on the same OS with
> the same version of java, javac and zlib (and probably a few other
> things I'm missing right now).
>
> Different javacs will create different class files. ZIP (and thus JAR)
> creation uses zlib under the covers and different versions may result in
> different deflated output.

That's fine. It's sufficient to be able to say that if you set up your
build environment to my exact but reasonable instructions (as you get in a
Debian source package, for example), you will get the same thing I got.
This would prove that I built the binaries from the source I said I did
just by comparing the single eventual output file.

Re: date formatting, I've added a "parseLenientDateTime" method to the end
of DateUtils.java. It's compatible with the date attribute to <touch> but
also accept milliseconds since epoch and a small range of ISO 8601-type
formats, so that dates output by other software can more easily be read by
Ant. Would it be okay if I submitted a patch that got <touch> to use
parseLenientDateTime as well? It's currently a bit awkward to make git, for
example, output a date that can be read by <touch>.

I've attached the output of git diff so you can see it, but what's the
correct way to submit the code to you?

Best wishes,

George.

Mime
View raw message