[ 
http://jira.codehaus.org/browse/MWEBSTART-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89689
 ] 

Kenney Westerhof commented on MWEBSTART-18:
-------------------------------------------

Jerome, the patch doesn't work  - some chunks failed. I don't see how MNG-2293 
doesn't work
as it's applied and released in 2.0.5. The unit test in 
shared/maven-plugin-tools/maven-plugin-tools-java succeeds,
which checks for the implementation parameter.

If you could fix the patch, or give another testcase or sample which doesn't 
work for you, I'll track it down
and see if it has anything to do with MNG-2293.

Btw, this doesn't seem correct:

    /**
     * The Sign Config
     *
     * @parameter 
implementation="${org.codehaus.mojo.webstart.JarSignMojoConfig}"
     */
    private SignConfig sign;

The ${ and } should be dropped - an interface name shouldn't be evaluated. 
Right now this means
  org.codehaus.mojo.webstart.getJarSignMojoConfig() which cannot be evaluated, 
and null results.
I think that's why the implementation field is empty in the plugin.xml.



> Allow different pluggable jar signers to be used
> ------------------------------------------------
>
>                 Key: MWEBSTART-18
>                 URL: http://jira.codehaus.org/browse/MWEBSTART-18
>             Project: Maven 2.x Webstart Plugin
>          Issue Type: Improvement
>            Reporter: David Boden
>         Assigned To: Jerome Lacoste
>             Fix For: 1.0-alpha-2
>
>         Attachments: JarSignerMojo.java, JarSignMojo2.java, 
> JarSignMojoConfig.java, MWEBSTART-18.diff, patch.txt, 
> webstart-jarsigner-api.zip
>
>
> Allow the use of other Jar Signer methods, not just Java's keytool utility.
> I've used the "Mapping Complex Objects" technique on this page: 
> http://maven.apache.org/guides/mini/guide-configuring-plugins.html
> SignConfig is now an interface which returns a fully configured version of a 
> Mojo which can sign jar files.
> There are 2 modifications required to the pom.xml:
> 1. <keystore/> section of the configuration has been moved inside the <sign/> 
> tag and renamed <keystoreConfig/>. This makes sense, because deciding whether 
> you want to delete and / or generate a keystore is all part of a particular 
> signing configuration.
> 2. Instead of just specifying <sign/>, users will need to pick their 
> implementation. To pick the normal keytool method of signature, the user will 
> specify:
> <sign implementation="org.codehaus.mojo.webstart.JarSignMojoConfig">
>     <keystore>...</keystore>
>     ... etc...
> </sign>
> Unfortunately, I can't think of a way of defaulting this.
> The code that I've given you compiles, but breaks some Junit tests. If you 
> could confirm that you're happy with this approach and are happy to commit 
> the changes, I'll then go ahead and sort out the test classes.
> By, the way... the way that I can implement my HttpJarSigner in this 
> architecture is very simple indeed. I just create an implementation of 
> SignConfig with an empty init() method and a getJarSigner() method that just 
> returns an instance of my HttpJarSigner with the serviceURL, username and 
> password setup. I then point to it in the pom.xml using:
> <sign implementation="com.lehman.HttpJarSigner">
>     <username>...</username>
>     <password>...</password>
>     <serviceURL>...</serviceURL>
> </sign>
> Note: I don't think that the generation and deletion of Java Keystore files 
> should be part of the maven webstart plugin. If someone really wants a new 
> keystore generated, they can configure the keystore using a different plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to