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.grigelio...@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.
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
