I think that is completely unintuitive no matter how "common" it is. I've had to use passwords in maven plugins before (e.g., SCM, release plugin), and it's not abbreviated like that.
So I did a "mvn -h"... and out of the some 20 options spelled out, none use abbreviations. So I am -1 on the spelling: it is not intuitive, no other option uses an abbreviated long version, and plugins commonly spell out "password". Paul On Thu, Feb 26, 2009 at 7:34 AM, Brett Porter <[email protected]> wrote: > It's now --encrypt-passwd (and --encrypt-master-passwd) based on Oleg's > suggestion. passwd is pretty common, and you can see it from mvn -h. > > Cheers, > Brett > > On 27/02/2009, at 12:30 AM, Paul Benedict wrote: > >> My only comment is this: >> >> I don't want to have to remember how you guys have uniquely >> abbreviated password. "Enc" is fine, "passwd" is a guessing game, and >> I believe should be spelled out. >> >> Paul >> >> On Thu, Feb 26, 2009 at 5:27 AM, Brett Porter <[email protected]> wrote: >>> >>> With 2.1.0 imminent, we'll need to finalise on this soon - are the >>> current >>> options satisfactory? >>> >>> Cheers, >>> Brett >>> >>> On 24/02/2009, at 1:41 AM, Brett Porter wrote: >>> >>>> >>>> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote: >>>> >>>>> >>>>> >>>>> Brett Porter wrote: >>>>>> >>>>>> >>>>>> I don't view this as a temporary measure - as my second comment said, >>>>>> you may need a password to get the plugin in the first place. How >>>>>> would you >>>>>> address this case? >>>>>> >>>>> I have never seen an environment where read-only access to central or >>>>> central replica is authenticated. Short of that it's just another >>>>> plugin to >>>>> be downloaded and used. Or I completely missed the question? >>>> >>>> That's right, it's the situation I was thinking of. I was thinking along >>>> the lines of a vetted repository where direct use of central is not >>>> used. >>>> It's maybe still unlikely that would be authenticated, but I wouldn't >>>> rule >>>> it out. >>>> >>>> Thinking it through, to me this actually feels a more natural fit in the >>>> CLI now, along with the other settings-based operations, pretty much >>>> symmetrical with the location of the operation to decode the passwords >>>> in >>>> the settings file. For a user, manipulation of the settings file is >>>> generally a set-up task, before you do anything else. This location also >>>> makes it very snappy, not going through the whole plugin cycle, and had >>>> very >>>> little impact on the code since it was already mostly achieved through >>>> the >>>> sec-dispatcher and cipher. A plugin for this would see infrequent >>>> releases - >>>> perhaps none - which seems an odd evolutionary cycle for an independent >>>> piece of code. >>>> >>>> Not that tied to it being in the CLI if a suitable replacement is >>>> already >>>> in place, but I hope this is somewhat convincing :) >>>> >>>> Cheers, >>>> Brett >>>> >>>> -- >>>> Brett Porter >>>> [email protected] >>>> http://blogs.exist.com/bporter/ >>>> >>> >>> -- >>> Brett Porter >>> [email protected] >>> http://blogs.exist.com/bporter/ >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- > Brett Porter > [email protected] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
