What you suggest relates to both http://jira.codehaus.org/browse/GRADLE-699
and http://jira.codehaus.org/browse/GRADLE-700
To be honest I do not remember anymore the specifics of GRADLE-700 beyond
GRADLE-699 (its been too many months).
I definitely like some of your other ideas. Accessing the system keychain
would be incredible, but I have no idea how viable nor difficult that would be.
Perhaps a Gradle-specific "keychain" would be doable? Specifically targeting
tasks that require authentication.
Prompting would be good too in the case of interactive building. However we
also have our CI server do this upload, so a way to manage this in a non-
interactive means is important.
On Saturday, October 09, 2010 04:45:19 pm Adam Murdoch wrote:
> On 10/10/2010, at 7:21 AM, Steve Ebersole wrote:
> > On a related note, I am having difficulty handing the username and
> > password for authentication for the upload. Directly embedding the
> > information as you did here does allow me to do the upload. However, I
> > obviously do not want to be checking in the build file with that
> > information. I tried extracting that information to
> > ~/.gradle/gradle.properties but that information is not being handled
> > correctly. I am pretty sure this is a matter of "timing" but I am not
> > sure what I need to do to get it to work:
> >
> > subprojects { subProject ->
> >
> > ...
> > if ( ! hasProperty('MY_JBOSS_USER') ) {
> >
> > MY_JBOSS_USER = "";
> >
> > }
> > if ( ! hasProperty('MY_JBOSS_PASS') ) {
> >
> > MY_JBOSS_PASS = "";
> >
> > }
>
> It looks like the closure has a hasProperty() method which takes precedence
> over Project.hasProperty(). And of course, the closure does not have
> properties called 'MY_JBOSS_USER' and 'MY_JBOSS_PASS'.
>
> A simple work-around is to use project.hasProperty() instead.
>
> Not sure what we should do about this one. Perhaps the best solution is to
> provide higher-level declarative capabilities so that people don't need to
> use hasProperty() in the build script. Perhaps something like:
>
> defaults {
> MY_JBOSS_USER = ''
> MY_JBOSS_PASSWORD = ''
> }
>
> This would specify values for the properties if the user has not provided
> any.
>
> Even better would be some way to declare that 'MY_JBOSS_USER' and
> 'MY_JBOSS_PASSWORD' are configuration values required by the
> 'uploadArchives' task. Then, if the uploadArchives task is to be executed
> in a build, Gradle could validate early in the build that those properties
> have non-empty values. Gradle would ignore their values if
> 'uploadArchives' is not to be executed. This way, a user who only needs to
> build locally never needs to know or care about the username and password.
>
> This could go further than just validation. For example, Gradle might
> prompt for missing values. It might provide some command-line tasks to
> list and manage configuration values. The GUI (and IDE) might provide some
> way to visualise your configuration. As might the Gradle plugin for a
> given CI server. Gradle might even integrate with the local keychain (or
> your enterprise single-sign-on solution) so you can manage build
> credentials the same way you do all your other credentials.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
> CTO, Gradle Inc. - Gradle Training, Support, Consulting
> http://www.gradle.biz
--
Steve Ebersole <st...@hibernate.org>
http://hibernate.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
