John, You got my point how things should work :) However, I don`t want to use gradlew. I already have special bootstrap tool which downloads jdk, gradle, gwt etc from internal repository to set up client machine or even build machine. I need to ensure build reproducibility what means I need to be able to build any previous project state with simple switch on command line. At the same time I need to be sure that all client machines always builds with latest build scripts and sources when no switch is specified. This can be done only before project build. Since init.script is also managed by my bootstrap (dedicated from project) I can use it for this synchronization from VCS.
So, Hans, Yes, I want to _execute_ the perforce ant task when the init script is evaluated. John Murph wrote: > > 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 > > -- View this message in context: http://old.nabble.com/Using-ant.p4sync-task-from-gradle-0.8-tp26829605p26886219.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
