[ http://jira.codehaus.org/browse/MJAR-32?page=comments#action_63457 ]
Jerome Lacoste commented on MJAR-32: ------------------------------------ Further explanation to help the reviewers. The original issue was fixed by accident as part of http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/JarSignMojo.java?rev=393237&view=diff&r1=393237&r2=393236&p1=maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/JarSignMojo.java&p2=/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/JarSignMojo.java Look in particular to the change line - verify.setJarPath( getJarFile() ); that became + File signedJarFile = signedjar != null ? signedjar : getJarFile(); ... + verifyMojo.setJarPath( signedJarFile ); Even though the fix for that NPE was put in, the unit tests initially provided in http://jira.codehaus.org/secure/attachment/19236/MJAR-32.diff that identified the issue weren't checked in as part of rev 393237. I thus updated the patch to match the current trunk. This identified a couple of new small related issues (other potential NPEs) identified by the same added test cases. So the patch http://jira.codehaus.org/secure/attachment/20071/MJAR-32-v2.diff contains both the tests cases that exploits the original issue and the new ones + the fixes to the new issues. Just apply the changes to the test classes without the changes to the source code and you will see the failures. You can also independently revert the fix that was checked in rev 393237 and replace verifyMojo.setJarPath( signedJarFile ); by verifyMojo.setJarPath( getJarFile() ); in the code and see how the newly added test cases will fail while no old test cases will fail. > [JarSignMojo] Verification of a signed jar fails > ------------------------------------------------ > > Key: MJAR-32 > URL: http://jira.codehaus.org/browse/MJAR-32 > Project: Maven 2.x Jar Plugin > Type: Bug > Environment: Linux Slackware 10.1, JDK 1.4.2_02 > Reporter: Pawel Pastula > Priority: Blocker > Attachments: MJAR-32-v2.diff, MJAR-32.diff > > > When verification is executed there is no way the verification can succeed > since if uses unsigned jar file instead of signedjar file: > verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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
