Hans Dockter wrote:
In a chat I had with Jon Cox he had some interesting ideas for
improving our command line and path handling.
Path handling:
It would be much nicer to have a *nix path separator for our project
and task paths. The reason why we use a colon as a separator is that
we have file and directory tasks, where the task name contains a slash.
What we could do instead it to allow a slash separator like:
/project1/subproject2/task3
If you have a directory task you can do:
/project1/subproject2/+/dir1/dir2
As directory paths are rarely referenced by there full path and are
usually not used as a primary task for execution, I can live with this
pretty well. One exciting thing about slash separators is that you can
use tab completion in case of a hierarchical project layout.
I like this.
Command Line usage:
gradle /project1/subproject2 clean compile +/dir1/dir2 -test
/project1/subproject2 sets the project where the tasks should be
applied to. Those tasks use name matching for execution. This means if
subproject2 has further subprojects with this task names in its
hierarchy, they are palso executed.
In general, this looks good. Your example is a bit unclear about the
details. Here's how I think it should work:
The first command line argument is optional and specifies the current
project. It can be either the project directory, a build file, or a
project path. If not specified, it defaults to the current directory. It
is a shortcut for (or replacement for) the --project-dir and --buildfile
command-line options.
This first argument would be used for 2 things:
- Determining which directory to start the search for a settings.gradle
file:
- If the first argument points at a file, start from the directory
containing that file
- If the first argument points at a directory, start from that directory
- otherwise, start from the current directory
- Determining which project to use as the starting project:
- If the first argument points at a file, use the project with that
build file. Fail if ambiguous
- If the first argument points at a directory, use the project with
that project dir. Fail if ambiguous
- If there is a project in the build whose path is the same as the
first argument, use that project
- Otherwise, use the project whose project dir is the same as the
current dir. Fail if ambiguous. Treat the first argument as a task name.
One thing I like very much is -test instead of -Dskip.test
Me too. How would we distinguish between these task exclusions and
command-line options? Would we keep the system property stuff? Does
-test exclude the dependencies of the test task as well?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
