I don't like the idea of making the maven-jar-plugin dependent on httpclient. Also, I'm not wild about creating an interface to allow grouping the JarSignMojo with some other class that won't be used from the jar plugin itself. Anything making use of such an abstraction should probably declare an adapter...
As for putting jar-signing into plexus, and making these two alternative implementations, I think that sounds nice for the longer term, but I'm not sure it's a good idea to disrupt the current release cycle of the jar plugin for that (since we'd have to implement/test such a new provider framework within plexus, then call a vote to release it ahead of the jar plugin's release).
David, if we did turn this into a plexus component set, would you be okay with us using your submitted HTTP-based signer in the plexus project, rather than directly within the maven project? It uses an MIT license.
What do others think about this as a solution? For the short term, I'd like to see the webstart plugin create a small adapter for the JarSignMojo, and implement a framework around it to allow the use of the HTTP-based alternative instead. From there, we can improve this framework, and eventually make a plexus component set out of it. Whether that component set lives in the maven/shared SVN space (my first vote) or the plexus project (not sure about concerns of code crossing in/out of the maven project here), we can eventually evolve it into a reusable project in its own right. However, I think such a project needs to evolve from the webstart plugin, not from the jar plugin.
In case we don't want the official maven-jar-plugin to depend on httpclient, another solution is to:
1- check
MJAR-35as is2- move this mojo to a plugin to the mojo plugin
MJAR-35as is 2- move this mojo to a plugin to the mojo plugin