Hi Adam,
On Jul 16, 2008, at 12:32 AM, Adam Murdoch wrote:
Hi,
I am currently porting a large ant based multi-project build to
gradle. Generally, the process has been very enjoyable, and the
build is looking heaps better. Thank you for creating gradle.
One thing I miss from our ant-based build is the ability to run a
particular target for all projects or for a particular ad-hoc
subset of projects from the top-level project. I'd like to add
something like this to gradle. In particular, I'd like to be able
to (optionally) specify tasks by path (rather than name) on the
gradle command-line. Something like:
gradle :child1:test :child4:test
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.
If so, I'd like to have a go at adding it. Some questions:
- I couldn't find anything much on the web site about contributing
to the project, eg how to provide patches, which jvms are we
targeting, testing, tracking in jira, etc
Good points. I gonna put them in the developer wiki soon. But I will
also answer some of them directly :)
Patches via Jira Issue and attachements
JVMs: 1.5 (We have started using the retrotranslator to produce an
additional JDK 1.4 compatible version. But there are still some
unsolved problems. )
Testing: JUnit 4.0 + JMock 2
Tracking in Jira? Do you mean svn tracking?
We are in the midst of refactoring our core from Groovy to Java. Any
contributions to the core should be in Java therefore.
- Does it make sense to keep the --non-recursive option, as the
same thing would be possible using :task notation?
Good question. I think it is a very uncommon, rather experimental
option anyway. It prevents descending which is usually not what you
want. And, as you have said, it is a subset in functionality of your
notation proposal. So I can't see why we should keep it.
- Should project default targets be interpreted the same way?
I think so, even though I don't see any use cases right now for
default tasks with an absolute path. But if only for the sake of
consistency they should behave the same way.
- Hans
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
