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.
P.S. This would not be a 0.9 feature, but having it in time for 1.0 would be
good, I think.
--
John Murph
Automated Logic Research Team
