On 17/06/10 1:45 PM, John Murph wrote:
I don't think project or system properties are good enough solutions
for this. We have two main uses for custom options: working and options.
1) Working. Our build uses the concept of distinct pieces (products,
installs, and distributions) that together guide the build in what
needs to be done. To use this, we needed a way to specify a
dist/install pair (the products which this pair describes are all
built). We call this the "working". We need a custom argument to set
the working (this saves the setting to a file for later use). If no
parameters are given, we list all available dists and installs so that
the user doesn't have to guess what the options are, or how to spell
things. Lastly, if the "working" custom option is followed by a
question mark, then we simply print the currently stored working (just
a convenience in case you've forgotten what you are working on!).
This sounds like this could be modelled as a task. Given that we want to
make it easier to configure tasks from the command-line, it might be a
good fit.
For example, we might support a command-line syntax something like this:
gradle [gradle-options] <task> [task-args]
then you could do:
gradle working - lists the available dists/installs
gradle working <dist> <install> - sets the current dist/install
gradle working ? - shows the current dist/install
One question is how the inputs are made available to the task. I would
think we could use some kind of declarative mapping, so that the
command-line args end up as properties on the task.
2) Options. Many parts of our system can be adjusted by options. We
persist these options in a file, but they can also be overridden on
the command line if desired. We could use project or system
properties for this, except for two things. First, each option is
given a name and description. This information is used to describe
the available options (and our Gradle UI plugin for IDEA has an
"options" tab that lists these options for easy use). Second, each
option is given a type (boolean, File, String, etc). These types are
used to validate before accepting new settings, and are used by the
aforementioned UI to show check boxes or file browsers or text
fields. These features give added value to our options. So, we have
a custom option called "option". Following this, arguments of "?"
list available options and their current values, arguments of
"<name>=<value>" set the current value of the specified option.
I think this could work the same way as the above.
Does that help to explain our needs better? I'm convinced that other
builds will have need for custom command line options if/when they get
complex enough. I do wonder if Gradle should provide built in support
for 2) above, however. Then the build could just define the available
options and not have to reinvent the wheel (this seems like a more
powerful version of the project properties that already exist).
I quite like this idea. We give the build author some way to declare the
human tweakable configuration for the build. Then, the UI (command-line,
GUI, IDE, CI server) can provide some way to:
- tell the user what configuration is available
- validate the values that the user has provided
- persist the user's configuration (if required)
- report on the config that was used to build some given artifacts
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
