On Mar 15, 2007, at 5:43 PM, Daniel Kulp wrote:
On Thursday 15 March 2007 20:07, Jeremy Boynes wrote:
There appears to be a bug in the gpg plugin for mvn. When I did this
release I used gpg:sign as a goal on the command line and that
consistently generates invalid keys for all except the last artifact
(in this case the JavaDoc) even in the local repo. When I did the
kernel modules I added a profile to the build which includes gpg:sign
and for those all artifacts seem to have valid signatures.
Rather than resign the deployed artifacts (just in case there is
something squiffy going on), I'll pull them down, add a profile to
the pom and then redeploy them.
I don't think there's a way to get the gpg:sign stuff to work
outside of
a profile and have it install/deploy correctly. You MIGHT be able to
get it to work on the command line via:
mvn verify gpg:sign install:install deploy:deploy
Basically, gpg:sign will sign the artifacts that are attached to the
lifecycle at the point in the lifecycle that it runs. (default is
verify phase) install/deploy then deploys those things.
It you tried it with:
mvn package gpg:sign deploy
that won't work. The "package" will run a lifecycle up to
package, then
run gpg:sign signing those artifacts, but the deploy would then start
another complete lifecycle which would rebuild the jars causing the
signature to be invalid. The pom doesn't change in the second build
which is why that sig is OK.
I'll try and update the gpg docs tomorrow.
This seems counter-intuitive - is there some reason why mvn can't
merge goals into one lifecycle (specifically when the plugin is just
attaching and not forking another one)? Guess this discussion should
be moved to [EMAIL PROTECTED] :-)
BTW the sig on the POM is also borked but that might be because the
pom is being regenerated.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
