Peter Voss wrote:
Hi Adam,
On 03.11.2009, at 03:31, Adam Murdoch wrote:
Peter Voss wrote:
Hi,
I have 2 projects "main" and "integration-tests". When I run "gradle
test" the integration tests are always run before the unit tests in
main are executed. This is not the behavior I like. I want to run
the unit tests first and if they fail there is no point running the
integration tests (which take much longer).
I couldn't find any good way to change that order (other than
renaming the projects). Adding a dependency from
:integration-tests:test to :main:test is also not what I want. When
executing "gradle :integration-tests:test" I want to run only the
integration tests (and all required artifacts to execute them). Also
running the tests from main would not be required to run the
integration tests.
Is there a way to set the execution order of tasks from different
sub projects without using dependencies?
Not yet.
You can probably work around this with something like:
task testsInAGoodOrder {
dependsOn ':main:check', ':integration-tests:test'
}
That would only execute tests of integration-tests project. If I use
task testsInAGoodOrder {
dependsOn ':main:test', ':integration-tests:test'
}
that would still run the tests of integration-tests first.
check depends on test, so the above should do what you want.
There's a few options for fixing this problem. One option is for
Gradle to understand that certain types of tasks, such as Test or
Checkstyle, are verification tasks, and to take this into account
when scheduling the tasks. It would schedule verification tasks as
early as possible in the build, and would schedule them in
fastest-first order (subject to dependencies), which would give the
earliest possible feedback of a breakage.
It's more a problem of ordering subprojects. In one of the user's
guide examples you are using a multi project build with "shared",
"api" and "services". I would prefer running tests in the following
order: shared -> api -> services (gradle would run in this order: api
-> services -> shared). If a test in shared fails I don't want to
continue with api or services. Or if the api tests fail, it could be
just due the reason that shared is broken.
That's exactly what I meant by 'as early as possible' above.
I feel that determining the ordering of sub projects should be under
the control of the build master and not the build system.
Probably, but we should also have Gradle provide a reasonable experience
without needing anything to be controlled.
Do you have any other examples where you would want to order things
differently to the default?
The user's guide says that sub projects are simply ordered in
alphanumerical order. I would suggest to use the order that is given
in the settings.gradle file. Would that be possible?
Thanks,
--Peter
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
