Bug 29097 - <signjar> should be inside <jar> task in order for dependency checking to work.
Summary: <signjar> should be inside <jar> task in order for dependency checking to work.
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2004-05-19 17:33 UTC by Alexey Solofnenko
Modified: 2008-12-03 22:32 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Solofnenko 2004-05-19 17:33:41 UTC
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"/>
    <signjar jar="archive.jar" alias="mdl" keystore="store.k" storepass="password"/>

execute it several times and every time archive.jar modification time is changed.
Comment 1 peter reilly 2004-05-19 17:49:02 UTC
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"/>
Comment 2 Alexey Solofnenko 2004-05-19 17:52:49 UTC
Do you think the problem is with in-place signing?
Comment 3 Alexey Solofnenko 2004-05-19 18:20:35 UTC
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 +?
Comment 4 Alexey Solofnenko 2004-05-20 17:45:27 UTC
There are several work-arounds in ANT. So this is an enchancement request.
Comment 5 Mike Hanafey 2004-09-02 11:38:35 UTC
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.
Comment 6 Mark Thornton 2004-10-06 14:44:49 UTC
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.
Comment 7 Steve Loughran 2004-10-06 14:52:16 UTC
should we be doing a case change? or a case insensitive comparison?
Comment 8 Steve Loughran 2005-03-23 16:41:08 UTC
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?
Comment 9 Alexey Solofnenko 2005-03-23 18:47:24 UTC
I still think it would be cleaner for <jar> to call nested <signjar> if there were
any updates. Bulk signing will still work.
Comment 10 Tony Strauss 2008-12-03 22:32:03 UTC
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.