On 03.11.2009, at 20:43, Adam Murdoch wrote:
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.
It doesn't. Tests of integration-tests still get executed first. The
fact that ":main:check" is the first dependency in the list doesn't
mean that it gets executed first. The task testsInAGoodOrder would
just ensure that both tasks ':main:test' and ':integration-
tests:test' get executed, but the ordering is still done in an
alphanumerical manner (as it seems).
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.
Of course. In most cases it is not necessary to control the ordering.
I would just say that the default behavior that sub projects are
ordered alphanumerically should be changed. You could use the ordering
in the settings.gradle file or in the dependsOn. It doesn't make a
difference for the cases where you don't care about the ordering, but
it at least gives you the opportunity to control the order easily
(other than renaming the sub projects).
Do you have any other examples where you would want to order things
differently to the default?
I am not aware of other things right now.
Thanks for your help on this.
--Peter
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
