On 10 September 2010 08:30, Simone Tripodi <simone.trip...@gmail.com> wrote: > Hi Seb, > thanks for your feedbacks. The problem I have is that even if I omit > the password waiting for the prompt, once the builds arrives ad the > gpg:sign execution, it is completely blocked :( > I'm using gpg 1.4.9, shall I have to upgrade to 2?
Current is 1.4.10. Gpg2 behaves very differently for passwords - it uses a background process that caches the password for a while. Unfortunately, gpg2 does not play well with secret keys on a USB stick, see: http://jira.codehaus.org/browse/MGPG-30 For testing purposes, I created a dummy key and added both keyname and password as a profile in my local settings file. It's then easy to use the test-deploy profile to check that the correct items are created and signed. For example, I just tried: mvn -Prc deploy -Ptest-deploy -PkeyTest and it created and signed the Maven and non-Maven artifacts OK. > Many thanks in advance, have a nice day, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Thu, Sep 9, 2010 at 9:10 PM, sebb <seb...@gmail.com> wrote: >> On 9 September 2010 19:54, Simone Tripodi <simone.trip...@gmail.com> wrote: >>> Hi all guys, >>> I'm trying to push an RC release, but the gpg plugin execution is >>> blocked when signing arifacts :( Follow below my attempts: >>> >>> mvn release:prepare -DdryRun=true -Darguments=-Dgpg.keyname=XXXX\ >>> -Dgpg.passphrase=XXXX >>> mvn release:prepare -DdryRun=true -Dgpg.passphrase=XXXX (the keyname >>> is defined as preferred in the gpg.conf) >>> mvn release:prepare -DdryRun=true (tried to insert gpg.passphrase in the >>> prompt) >>> >>> Do you have any idea why? Many thanks in advance, >>> Simo >> >> I use a profile in my settings.xml which defines the keyname, so I >> don't have to remember the hex string. >> One can also define gpg.homedir and gpg.executable (if required) >> >> The password you can omit - it should be prompted for, but how depends >> on whether you are using gpg1 or gpg2. >> >> For testing gpg signing, you can use the new "test-deploy" profile. >> >> Don't you need to use mvn deploy ? >> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Sep 6, 2010 at 10:03 PM, Simone Tripodi >>> <simone.trip...@gmail.com> wrote: >>>> Hi Rahul, >>>> don't worry I won't publish the site before the release; about the >>>> Menu reorganization I like the b) too, it is much more coherent with >>>> previous releases. >>>> Thanks a lot, have a nice day, >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Mon, Sep 6, 2010 at 6:23 PM, Rahul Akolkar <rahul.akol...@gmail.com> >>>> wrote: >>>>> On Mon, Sep 6, 2010 at 9:49 AM, Simone Tripodi <simone.trip...@gmail.com> >>>>> wrote: >>>>>> Hi all, Rahul, >>>>>> what about the latest deployed website? >>>>> <snip/> >>>>> >>>>> Looks good overall, though I haven't taken a fine-toothed comb to it. >>>>> >>>>> >>>>>> Can I proceed modifying the >>>>>> homepage in order to propose a release? >>>>> <snap/> >>>>> >>>>> Sure, but please don't deploy it after those changes until the release >>>>> is done. Before posting the vote, the site is previewed w/ the rc >>>>> profile (-Prc) in the site-deploy command -- this will deploy the site >>>>> to the pao/commons/builds area where the other artifacts for the vote >>>>> will get posted as well. >>>>> >>>>> WRT the new additions to the LHS menu, currently we have (indentation >>>>> implies nesting): >>>>> >>>>> Developers Guide (SVN latest) >>>>> Core APIs >>>>> Plugins >>>>> Substitution >>>>> XML Rules >>>>> Annotations >>>>> FAQ >>>>> >>>>> I see two options for the 2.1 release: >>>>> >>>>> (a) Use the above (but change SVN latest to 2.1) >>>>> >>>>> (b) Use the following: >>>>> >>>>> Release 2.1 (Current) >>>>> Guide >>>>> Core APIs >>>>> Plugins >>>>> Substitution >>>>> XML Rules >>>>> Annotations >>>>> FAQ >>>>> Javadoc >>>>> Release Notes >>>>> >>>>> Release 2.0 >>>>> ... (current content for 2.0 menu) >>>>> >>>>> >>>>> I think (b) will work better as it aligns with menu for previous >>>>> releases -- note the FAQ indentation in (b) BTW as its different -- >>>>> WDYT? >>>>> >>>>> -Rahul >>>>> >>>>> >>>>>> Thanks in advance, all the best, >>>>>> Simo >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://www.99soft.org/ >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Sep 5, 2010 at 12:46 AM, Rahul Akolkar <rahul.akol...@gmail.com> >>>>>> wrote: >>>>>>> On Sat, Sep 4, 2010 at 3:11 PM, Simone Tripodi >>>>>>> <simone.trip...@gmail.com> wrote: >>>>>>>> Hi Rahul, >>>>>>>> thanks a lot for your feedbacks, actions have been completed following >>>>>>>> your suggestions. >>>>>>>> my final 2 questions: >>>>>>>> - I didn't find any reference on wiki about >>>>>>>> ${commons.deployment.protocol}... can we have a private chat? >>>>>>> <snip/> >>>>>>> >>>>>>> Sure, though it helps to have things in the list archives for the next >>>>>>> person in line, so the responses are best when archived :-) >>>>>>> >>>>>>> The deployment protocol bit is for wagon and defaults to scp (see >>>>>>> parent pom). If you want to use some other (for example, scpexe with >>>>>>> PuTTY), then it can be changed via an active profile in >>>>>>> ~/.m2/settings.xml. If you've used the m2 release plugin before, you >>>>>>> probably don't need to do anything new for Commons. >>>>>>> >>>>>>> >>>>>>>> - Is it the case to migrate the group id to org.apache.commons? >>>>>>> <snap/> >>>>>>> >>>>>>> No, not for 2.1 (archives have this topic at length). >>>>>>> >>>>>>> -Rahul >>>>>>> >>>>>>> >>>>>>>> Many thanks in advance, namaste >>>>>>>> Simo >>>>>>>> >>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>> http://www.99soft.org/ >>>>>>>> >>>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
