On 11/10/2010, at 6:38 AM, Steve Ebersole wrote: > Had another thought. Can the configuration of a task be altered just before > it > executes? What I am think is a custom plugin (buildSrc variety) which does > some configuration of the uploadArtifacts task which amongst other things > would > look up these properties and inject them into the authentication config for > our > repositories. > > I'd wire up a dependency between the uploadArtifacts task and a task from > this > plugin that does the above mentioned steps. Then the custom plugin not > finding > the user/pass could log a warning. Essentially its doing some "on demand" > configuration of the uploadArtifacts task. > > That should work?
It should. This is the general approach we want to take for conditional task configuration, and over time we'll add stuff to make it work better. For example, you don't yet have a huge amount of control over when the configuration task executes during the build. If it's going to do any warning or validation, you want it to run as early as possible. I imagine that any kind of declarative configuration handling we add is going to end up structured as tasks in a similar way. > > On Sunday, October 10, 2010 08:59:33 am Steve Ebersole wrote: >> 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 > > -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
