signjar if a file in a fileset is newer than target

["Erik Dybdahl (evident)" <er...@evident.no>]

Hello,
The SignJar task will, if you specify the signedjar attribute, check if the
jar is updated, before it signs the jar and places the result in signedjar.
It can also deal with filesets, but in that case it will sign all files
without any check. Since signing is a heavy process, this is undesirable if
a lot of files are involved.

The Copy task works in the desired way, because it has a "todir" attribute.

Since the execute-method may be overridden one might suggest making a
subclass of SignJar.
But this is not possible because the method doing the actual work,
doOneJar(), is private, and it is called with an empty "targetJar" parameter
when using filesets.

What is needed here, seems to be a generic task, that behaves like Copy, but
where it is possible to specify (by overriding a method) an optional,
additional operation that is to be performed on the copied file (leaving
uncopied files untouched). In fact, this could have been the Copy task
itself.
Tasks like SignJar could then extend this task instead of directly
subclassing Task.

I've found the same issue discussed under the topic "signjar which does more
than one file and dependency checking" from last year (checking if target is
signed already will not do for me, though). Also "executing task for each
file in fileset" seems to discuss a related issue.

To meet my immediate need I added a new method, doOptionalOperation(String
fromFile, String toFile)  to the Copy task, which is invoked after the call
to fileUtils.copyFile (subclassing Copy to accomplish the same is not
straightforward, it would have).
Then I created a new SignJars Task that extends the modified Copy task,
implements the set-methods from (and delegates them to) SignJar, and
overrides the doOptionalOperation() method to execute SignJar on "fromFile".

This works, but it is not a very elegant solution.
However, adding the doOptionalOperation method to Copy may also serve other
needs, present or future.
Putting the call to fileUtils.copyFile in a method that can be overriden may
be an alternative, since that will not alter the current behaviour of Copy
at all.

Anyway, if anyone is interested, I can submit the code.

Regards,
Erik Dybdahl




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>