On 12/06/10 2:13 AM, John Murph wrote:
We have a need to have custom command line arguments for Gradle.
Currently, we have done this via a hack using settings.gradle, like this:
if (startParameter.taskNames.contains('custom-option'))
{
... do stuff ...
}
Then using indexOf to figure out where that option is in the list of
taskNames so that arguments of the option can be processed. In our
case, this block always ends in System.exit because it's more like
"-version" in concept. However, such a technique could allow
execution to continue by removing these "options" from the list of
taskNames.
This technique is fairly bad, however. These options cannot look like
options, but instead must look like tasks (they can start with '-' or
'--' like options normally do). Gradle also has no knowledge that
such things are happening and so cannot handle them better (for
instance, instead of calling System.exit, we should instead be using
buildCompleter.exit like is done in org.gradle.launcher.Main.execute).
What I would like is built-in support in Gradle for custom command
line arguments. I imagine it working like this:
1) In DefaultCommandLine2StartParameterConverter.convert, if
parser.parse throws an UnrecognizedOptionException, add that option to
a list (which lives in StartParameter), remove the argument and retry
the parse. (An issue is how to handle arguments for an option -- how
many arguments do you remove before retrying the parse.)
2) Add syntax for init/settings/build scripts to "register" options
and handlers for these options.
3) After configuration phase, if there were any unrecognized options
from step 1, then see if any custom option handlers have been
registered that can handle these options. If so, dispatch to the
appropriate handlers.
4) If there are any remaining unhandled options after this, then error
before proceeding to execution phase.
This is not a fully developed idea, but I wanted to see if anybody
thinks that it is worth pursuing. In my mind, it fits with the idea
of "using Gradle to create a custom build system," but it feels maybe
a bit excessive as well.
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)
--
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
