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!). 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. 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). That fits with Gradle being more of a toolkit and less of a build framework. On Wed, Jun 16, 2010 at 9:45 PM, Adam Murdoch <[email protected]> wrote: > > I'd like to understand the problem a little better. Why can't you use > project or system properties for solving this? (ignoring the fact that the > project properties aren't visible to the settings script. This we can easily > fix) > > -- John Murph Automated Logic Research Team
