On 2012-08-15 1:46 PM, Laird Nelson wrote:
On Wed, Aug 15, 2012 at 12:54 PM, Eric Kolotyluk
<[email protected] <mailto:[email protected]>> wrote:
Basically, when I have a situation where I have some username and
password
for the scm plugin, where do I store such information, and how do I
configure the scm plugin, the release plugin, etc. to find that
information?
When a server of any kind is referenced in a pom.xml, if you have an
equivalently-identified <server> element in your settings.xml, then
its <username> and <password> entries are used for credentials. (See
http://www.sonatype.com/books/mvnref-book/reference/appendix-settings-sect-details.html#appendix-settings-sect-servers.)
That text would be more clear if it specified which settings.xml file -
as there are two. Do you mean the global settings.xml file or the
personal/local settings.xml file in the user's home directory
${user.home}/.m2/settings.xml? And what would this look like if I was
trying to handle credentials for Perforce via the scm or release
plug-ins? The use of the term 'server' here is kind of confusing.
A settings.xml file is a local file stored under your home directory,
in a directory named .m2. (See
http://maven.apache.org/ref/3.0.4/maven-settings/settings.html.)
OK, that makes sense, and it would make more sense if
http://www.sonatype.com/books/mvnref-book/reference/appendix-settings-sect-details.html#appendix-settings-sect-servers
was clear on that.
Storing your password in plain text in your settings.xml file is
sometimes (always?) bad practice. In that case you should look into
encrypting the passwords that are contained therein. (See
http://www.sonatype.com/books/mvnref-book/reference/appendix-settings-sect-details.html#appendix-settings-sect-encrypting-passwords.)
OK, that link is much better, thanks :-)
Hope that helps,
Best,
Laird
--
http://about.me/lairdnelson
I think much of the problem with technical documentation these days is
that many people still write as if they expect people to read the whole
document. There is too much context because important information is
factored out. Increasingly, people do not read whole documents anymore
(I know I don't) and get to parts of the document often by URL or Google
search, so they have no context. Consequently, documents need to be more
context free. True this makes them wordier and longer, but it meshes
more with how people read theses days.
For example, I am often frustrated by the abuse of acronyms. Too many
writers define the acronyms maybe once at the beginning of the document
(or not at all). If you skip to the middle of the document you have no
idea what the acronyms mean, or where they might be defined.
For the most part, I strive to make my writing increasingly context
free, or I keep redefining the context as often as possible.
Cheers, Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
