Currently the task always executes. By putting it inside <jar>, <signjar> can be executed only if the archive was updated. Simple test: <?xml version="1.0" encoding="iso-8859-1"?> <project name="test" default="all" basedir="."> <target name="all"> <jar destfile="archive.jar"> <fileset dir="." includes="*.xml"/> </jar> <signjar jar="archive.jar" alias="mdl" keystore="store.k" storepass="password"/> </target> </project> execute it several times and every time archive.jar modification time is changed.
The doc of the signjar saids that it only signs it if the jar file is unsigned, so it would be a bug if it did update the file. As a work-around, one could use the signedjar attribute. <signjar jar="archive.unsigned.jar" alias="mdl" keystore="store.k" storepass="password" signedjar="archive.signed.jar"/>
Do you think the problem is with in-place signing?
With signedjar attribute <signjar> signes the jar once more time and then stops doing it. Can it be that in FileUtils.isUpToDate() ther should be -granularity, not +?
There are several work-arounds in ANT. So this is an enchancement request.
I think the real issue is that when a jar is signed the next jar task to create the jar will see the manifest is different, and so the jar task will recreate the jar file even though the contents is otherwise unchanged, necessitaing re-signing. Nesting a signjar element would not change this. The jar task needs to be able to figure out when the manifest has changed only because signing has occurred, then the "lazy" attribute of signjar would prevent unessary signing, but only because the jar task avoided unnecessary work.
SignJar is always executing because the alias used is lowercase, but the test for whether a jar is already signed when not using the signedjar option is incorrect (it assumes that the alias is uppercased when composing the signature entry, which it isn't at least for some JDK). Using the signedjar option is horrible if you have more than a handful of jar files to sign.
should we be doing a case change? or a case insensitive comparison?
CVS_HEAD lets you specify a destdir; you can bulk sign a set of jar files with the output in a new directory, timestamps are used for dependency checking. Can we close this as WONTFIX?
I still think it would be cleaner for <jar> to call nested <signjar> if there were any updates. Bulk signing will still work.
I think that there is an additional problem with signjar's dependency checking. In particular, if the signed jar is a different file than the unsigned jar, signjar will recreate the signed jar if its modification time is the *same* as that of the unsigned jar. This leads to the following pattern: Build #1: Build unsigned jar Build signed jar Build #2 Build signed jar (because the signed and unsigned jars created in Build #1 have the same timestamp). Build #3 Nothing (because Build #2's signed jar has a later modification timestamp than Build #1's unsigned jar). This bug means that using signjar's preservelastmodified attribute results in the jar always being rebuilt. I think that the correct behavior (followed by the copy task, for instance) is for signjar to rebuild if and only if the unsigned jar's modification time is later than that of the signed jar.