On Nov 7, 2008, at 9:14 PM, Adam Murdoch wrote:
Gregory BOISSINOT wrote:
Hi,
I have started to develop the Hudson Gradle plugin :
http://hudson.gotdns.com/wiki/display/HUDSON/Gradle+Plugin
For the moment, the plugin implementation only invokes the gradle
command.
(for windows plateform, I will very soon support gradle.bat (for
gradle
0.5-SNAPSHOT) instead of gradle.exe that have problem with
ERRORLEVEL)
I read the Gradle user guide with attention. But in chapter 4.4,
it is
suggested that a Gradle integration in a CI might start by its
main method
and for supporting environment property start with
ORG_GRADLE_PROJECT_
I do not understand it.
Is it possible to give more explication on this?
I think that section of the user guide is trying to tell you a
couple of different things at once:
First, there are a number of methods you can use to set properties
on a project from outside the build:
- Use -Pname=value on the command-line
- Use gradle.properties in the same directory as the build file
- Use gradle.properties in the user's home directory
- Use a system property whose name starts with org.gradle.project,
eg -Dorg.gradle.project.name=value will set property 'name' to 'value'
- Use an environment variable whose name starts with
ORG_GRADLE_PROJECT, eg ORG_GRADLE_PROJECT_name=value will set
property 'name' to 'value'
All of these methods can be used regardless of how Gradle is launched.
Secondly, there are a number of ways you can launch Gradle:
- Using the gradle or gradle.bat script
- Calling Main.main() directly
- Using the Gradle class (in Gradle 0.5).
A CI server plugin could use any of these methods to launch Gradle.
And any or all of the methods above to set properties on the project.
I'd say that using Main.main() has pretty much been deprecated in
favour of using the Gradle class.
Definitely the Gradle class should be the way to go for CI
integration I would say. But until recently the logging has still
been configured in the Main class. This has changed with the latest
commits to trunk.
Another issue is configuration. Main works with the command line
arguments, Gradle with a StartParameter object. Main has the
functionality to create a StartParameter object from command line
arguments. This is inconvenient for your use case I would say. I
guess in the CI UI the users want to use command line arguments to
express what the build should do. Therefore the functionality to
create a StartParameter object from command line arguments should be
factored out from the Main class. Right now you can say:
Gradle.newInstance(StartParameter startParameter). We probably should
offer something like: Gradle.newInstance(String... commandLineArgs).
One nice thing for a CI tool with the Gradle class is, that you can
register listeners.
There is one more thing to say on this topic. The gradle start script
uses the BootstrapMain class (which the calls the Main class). The
job of BootstrapMainis to read the lib jars from the Gradle
distribution and to put them into a classloader. When using the
Gradle class directly you can just put the Gradle libs in the
classpath the normal way. But this could lead to issues when building
Groovy projects. If so, you could copy from BootstrapMain the
classloader setup. We want to provide a better solution for this
problem in the future.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
