On Mon, Dec 21, 2009 at 10:50 AM, Hans Dockter <[email protected]> wrote:
> > > On Mon, Dec 21, 2009 at 10:58 AM, Narco <[email protected]> wrote: > >> >> I see, is there a JIRA issue? >> I have a bit complicated problem since I need to get it working from >> init.gradle script where object configurations does not exists. Please >> help. >> > > You don't need configurations. You just need file objects for injecting the > jars into the classloader. > > Do you want to _execute_ the perforce java task when the init script is > evaluated? > > Wow, that's interesting. I envision giving someone gradlew (and friends) and an init.script. When they run it, it could pull down the "correct version" of Gradle (this makes it a bit different from gradlew, though...) and then run the init script. That script could then pull the necessary sources from VCS (Perforce, or whatever) and then build it, which means I want to _execute_ tasks from my init script. For what I'm thinking, I would want gradlew to get a specific release of Gradle, but be able to change that without touching the client machine. Maybe have gradlew get Gradle from my own repository and use the latest version (I'm assuming I would never want to go back to an older version). In gradle-wrapper.properties, can distributionVersion be '0.9+'? Or could I get gradlew to pull down a new gradle-wrapper.properties from my binary repository and then use that properties file to find the Gradle to use? BTW, the reason that I care is when I'm thinking about integrating Gradle into our build process that involves non-software development teams. For instance, we have a team that produces other data that goes into our product. I want these teams to "publish" their contributions to our internal binary repository. But, that's a lot of people (say 50 or so), so I don't want to have to maintain their Gradle installations. If I could just put Gradlew (and a simple init script) on their machines the first time and be able to push stuff to the repo to "update" them on the fly it would simply maintenance. All this makes me wonder if gradlew could be changed to use a script rather than a properties file. Then I could put logic into it to do things like get more data from the repository and use that data to find the version of Gradle to extract. Which goes towards Gradle being a script execution engine with support for automatically downloading and using plugins (think Ruby gems). The "Gradle install" becomes 20 or 30 KB, and everything else gets downloaded on demand. Anyway, just something to think about. Sorry Narco, not trying to hijack your thread. I'll shut up now. :) -- John Murph Automated Logic Research Team
