On 1 March 2012 14:01, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Thu, Mar 01, 2012 at 02:46:33AM +0000, sebb wrote: >> On 29 February 2012 23:04, Gilles Sadowski <gil...@harfang.homelinux.org> >> wrote: >> > Hi. >> > >> > Trying the following command (from the wiki "UsingNexus" page): >> > >> > $ mvn release:prepare -DdryRun=true >> > >> > Getting to the signing step: >> > ---CUT--- >> > You need a passphrase to unlock the secret key for >> > user: "Gilles Sadowski (ASF code signing) <er...@apache.org>" >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28 >> > >> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session >> > >> > You need a passphrase to unlock the secret key for >> > user: "Gilles Sadowski (ASF code signing) <er...@apache.org>" >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28 >> > >> > Enter passphrase: [INFO] gpg: Invalid passphrase; please try again ... >> > >> > You need a passphrase to unlock the secret key for >> > user: "Gilles Sadowski (ASF code signing) <er...@apache.org>" >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28 >> > >> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session >> > [and again...] >> > ---CUT--- >> > >> > When I try with this command: >> > >> > $ mvn -DdryRun=true -Dgpg.keyname=er...@apache.org \ >> > -Darguments="-Dgpg.keyname=er...@apache.org" \ >> > -Prelease release:prepare >> >> Dunno who wrote that, but it surely should not be necessary to provide >> the keyname twice? >> One of the parameters must surely be redundant, or the release plugin >> is even worse than I thought ... > > In the document, it is presented as the alternative to > > $ mvn release:prepare -DdryRun=true > > which behaves exactly the same (i.e. does not work here as indicated above > and below, in a way depending on the presence or not of "-Prelease").
What does <<in a way depending on the presence or not of "-Prelease">> mean? If you have only put the gpg.keyname in the release profile, the setting won't be available unless the profile is activated. I've no idea whether the release plugin activates the release profile if dryRun is true. Properties have to be in profiles, but you can create a profile that is active by default for any properties you want always to be defined. >> >> > It gets stuck[1] after printing >> > ---CUT--- >> > INFO] [INFO] Building zip: >> > /home/eran/devel/SVN/commons-math/trunk/target/commons-math3-3.0-SNAPSHOT-bin.zip >> > [INFO] [INFO] >> > [INFO] [INFO] --- maven-site-plugin:3.0:attach-descriptor >> > (attach-descriptor) @ commons-math3 --- >> > [INFO] [INFO] >> > [INFO] [INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ >> > commons-math3 --- >> > ---CUT--- >> >> Have you managed to get the following working? >> >> $ mvn package gpg:sign -DskipTests >> >> Put the gpg.keyname in settings.xml. >> If you have more than one, put them in profiles. > > Yes, that works. [With the <gpg.keyname> in a profile named "release".] > It prompts for the pass phrase and finishes successfully. That's a bit odd, because I don't think the release profile will be activated. However, I suppose if you only have one key it might pick that. >> Until you can sign locally, there's no point trying to use maven >> release - if you really want to use that. >> I find it better to use the manual method described here: >> http://wiki.apache.org/commons/UsingNexus#Create_the_SVN_tags_.28Manual_method.29 >> >> Much easier to understand, and no need to revert trunk when the >> release tag fails. > > IMHO, all the more reasons to further clean up the document, leaving there > only what is confirmed to work. I think that, as a mini-howto, it should not > contain more than the strict minimum, i.e. the necessary and sufficient > steps to get to the goal of producing the release. Any alternative step (or > system-specific command) should preferrably be moved to a footnote (or a > dedicated wiki page) in order not to disturb from the main flow. > Yes of course. > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
