Adam Murdoch wrote:
Hans Dockter wrote:
Hi
Adam,
On Jul 21, 2008, at 1:33 PM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi Adam,
On Jul 16, 2008, at 12:32 AM, Adam Murdoch wrote:
More specifically, when a name is
provided on the command-line, if it starts with ':', it is treated as a
task path, and the task with that path is executed (along with its
dependencies). Otherwise, it is treated as it is currently, where all
tasks with the given name are executed (with dependencies).
Would it make sense to add this behaviour to gradle?
That would make a lot of sense. In fact, as soon as we support
arbitrary multi-project layouts this is even required. Right now the
only way to achieve what you want (i.e. partial build) is to go to the
subproject folder and execute the build from there. This works only
because we assume a hierarchical layout and are able to find the root
by looking for a settings.gradle file. As soon as we can't make any
assumptions about the layout, you either have to specify the root when
you are in the subproject or the subproject, if you are in the root.
The latter is what you want.
In the case where a path is provided on the command-line, should we
search for the task in the current project (and its sub-projects) or
the root project (and its sub-projects)?
ie in the water sample, if I am in the krill sub-directory, should I be
able to run gradle :bluewhale:hello? Or just :krill:hello?
Searching in the current project would be consistent with the case
where a name is provided. Searching in the root project would be
consistent with the behaviour of task dependsOn, and possibly a better
fit for arbitrary multi-project layouts as we don't need to know what
the current project is.
What about? If we take the future arbitrary layouts into account:
- You can run a gradle build from anywhere if you specify the root
project and an absolute task name (anywhere is of course also from a
subproject)
For arbitrary layouts we might do also:
- If you specify a relative pathname in a subproject and specify a root
project, the task with the relative task is executed against the
subproject.
For hierarchical layouts:
- If you specify a relative pathname in a subproject we continue to do
what we do know.
- If you specify a absolute path in a subproject, the same happens as
if you do it from the root project.
What do you think?
I think it sounds good. Just to clarify a few things:
For arbitrary layouts, is the plan to keep the domain model the same as
we have, and simply be more flexible about where the artifacts
(build.gradle, etc) can be physically located?
That is, will we always end up with a hierarchy of projects, regardless
of where those projects are located and how they are configured? And
will we always have a current (sub)project, regardless of how we
determine which one it is?
I think there are 3 types of paths which could be specified on the
command-line:
- an unqualified path, ie one without a ':' character. eg 'hello'
- a relative path, ie unqualified-path ( ':' unqualified-path )+ eg
'krill:hello'
- an absolute path ie ':' relative-path eg ':krill:hello'
Given the above, we could interpret each type of path as:
- unqualified path: execute all tasks whose path matches current-project:**:path
(using an ant style pattern here) where current-project is the
path of the current project and path is the value supplied on
the command-line
- relative path: execute all tasks whose path matches current-project:path,
or maybe current-project:**:path
- absolute path: execute the task whose path matches path
I've created a jira issue for this, and attached a patch which pretty
much implements this.
http://jira.codehaus.org/browse/GRADLE-165
I made a few structural changes as part of this patch. I moved the
knowledge of selecting which tasks to execute, project default tasks,
and validation out of Build and BuildExecutor behind a new TaskSelector
interface and a couple of implementations which Build delegates to.
I also removed the --non-recursive command-line option.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
