On Tue, Dec 22, 2009 at 11:14 AM, Narco <[email protected]> wrote:
>
> 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.
>
You can use the plain Groovy AntBuilder in the init.gradle.
AntBuilder ant = new AntBuilder()
ant.getClass().classLoader.addURL(new
File('pathWithCustomAntTask.jar').toURL()) }
ant.someAntTask {
}
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
>
> 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
>
>
>
