On 15/07/2011, at 5:00 PM, [email protected] wrote: > Branch: refs/heads/master > Home: https://github.com/gradle/gradle > > Commit: 81e1378cc184abe8553a99f5ffd58ba1128ecf9b > > https://github.com/gradle/gradle/commit/81e1378cc184abe8553a99f5ffd58ba1128ecf9b > Author: Luke Daley <[email protected]> > Date: 2011-07-15 (Fri, 15 Jul 2011) > > Changed paths: > M subprojects/docs/src/docs/userguide/signingPlugin.xml > > Log Message: > ----------- > Fixed example of using the Java 6 console for prompting for signing > credentials.
I don't think we should be encouraging people to use the console. It just doesn't work in enough places: CI builds (as you pointed out), or the daemon, or from the IDE, or when using java 5, or piping through another command, or when we go parallel/distributed, or .... The current plan for credentials management is something like this: 1. Introduce the concept of credentials to the model, as maybe an explicit type, or annotations on a property, or both. 2. Introduce the concept of a credentials provider, which is responsible for filling out the credentials details. 3. Add a basic implementation which might do something like this: check for specific project properties, and use them if provided. Otherwise, if a console is available, use it to prompt the user. Otherwise, fail. 4. Allow additional credentials provider implementations to be added, and maybe package up a few as plugins (a provider which uses ~/.ssh would be nice. As would an LDAP provider. Or a native keychain provider). 5. Expose the credentials prompting through the tooling API. 6. Generalise this to some kind of 'build configuration' capability through the tooling API, that allows clients to query and mutate build configuration. Where 'build configuration' means the pieces of information that the build user can either tweak, or must provide in order to use the build. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
