> David,
>
> Please try to be more specific with your issues. If possible come with
> a use case and reduced project that reproduces the problem (provide
> the pom.xml, the mvn -X output, etc...). Always specify the maven
> version(s) as well as the plugin version(s) you used when you had the
> problem.
Sorry. Maven 2.0.6 and the released version of webstart-maven-plugin (I don't
know how to find the version).
then 1.0-alpha-1, that's the only one released.
Isn't the version displayed when you do mvn -X ?
> About your particular problem:
> - what kind of complain do you get on your first run ?
jarsigner error: java.lang.RuntimeException: keystore
load: /home/dcorbin/w....
Never seen that. Did you enable verbose ? Can you try to reexecute the
sign command to check why it is failing that way ? I cannot do much
otherwise!
> - how do you know it failed to sign them ?
I was watching it closely. The keystore setting was wrong, and if it signed
then without that, I'd be really worried. Not to mention, signing all the
jars takes about 3 minutes and the failure happens in about 5 seconds.
OK. So the first failure was due to a user configuration failure ?
> Did you check the resulting
> jars in the relevant target folders ?
Just to see that they were there.
> - any interesting info under mvn -X ?
details of why it failed, but that's not my complaint.
> - on the second run, any particular output (in standard run or under mvn
> -X) ?
[DEBUG] Some dependencies may be skipped. Here's the list of the artifacts
that should be signed/packed: []
[DEBUG] File: commons-logging-api-1.0.4.jar modified: false
[DEBUG] lastModified: 1176461710000 plugin start time 1176461957796
...
[DEBUG] signJars
in
/home/dcorbin/workspace/inventory.ws/com.enttek.concessions.homeoffice/webstart/target/jnlp
found 0 jar(s) to sign
[DEBUG] compare
com.enttek.concessions:concessions-homeoffice-client:jar:0.18.0:compile with
com.jgoodies:forms:jar:1.0.7:compile: false
[DEBUG] compare
com.enttek.concessions:concessions-homeoffice-client:jar:0.18.0:compile with
commons-logging:commons-logging:jar:1.1:compile: false
[DEBUG] compare
com.enttek.concessions:concessions-homeoffice-client:jar:0.18.0:compile with
cglib:cglib-nodep:jar:2.1_2:compile: false
> Note that the plugin doesn't try to resign jars so that may be why it
> doesn't fail on the second run.
I understand (and appreciate) that. But my point is the way it's determining
that it can skip signing is flawed. If you're going to use timestamp alone,
then when you fail, you need do one of the following (or some variation:
a) remove the local copies that did not get signed
b) examine the jar for a signature
c) pull them to a temporary location, and sign/copy as an atomic
operation (not sure if signjar supports this, but it kind of looks like it
might.
d) some other better detection method
OK now I get your problem. If you have a failure, then jars are
already copied and the mechanism to identify whether or not the jars
should be resigned is not good enough.
That should be clearly an improvement. The best would be to be able to
check the signature.
I would lean toward doing something like
copy the file under a special name (i.e. myjar.jar_unsigned) sign it
and rename it to the final jar. That way only signed jars will have
the correct name.
Does that sound good to you ? Would you like to try to create a patch
for that ? Please open an issue in Jira.
Note: there are things that will always require you to make a clean:
e.g. if you change your key. maven cannot detect this. Would be nice
to add a faq on that particular issue. Feel free to send a patch as
well :)
On a loosely related note:
Would it be feasible to have signed jars put back into the repository with a
classifier? Maybe only for certain artifacts, or non-snapshot versions? Or
compare timestamps for two repository artifacts? (Not sure what's really
practical here.)
You basically want to minimize the number of jars to be signed again and again.
That would be nice. Have to see how this plays with the minijar plugin.
Putting back the signed jar into the repository should be possibke,
maybe as a functionality of the jar sign mojo.
As thing stand now, doing a "mvn clean" adds a bunch of (otherwise)
unnecessary time for me.
Only if you've made a configuration failure, right ? :)
let me know if you can or not create the issues and the patches.
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
