Hi,
one thing I find inconvenient with Gradle multi-project builds at the
moment, is that dependent projects are rebuild although it would not
be necessary.
Let's look at an example:
root
- commons
- webservice (has a compile dependency on commons)
Let's look at some use cases
1.)
webservice> gradle compile
current:
does compile, test and uploadLibsInternal on commons
does compile on webservice
should do: if commons hasn't been touched an existing jar of commons
should be used. If commons has been touched or no jar does exists,
the commons-jar should be build, but without being tested.
2.)
webservice> gradle test
current: like above except that webservice is tested
should do: If commons hasn't been touched an existing jar of commons
should be used. If commons has been touched or no jar does exists,
the commons-jar should be build with being tested.
3.)
webservice> gradle clean compile
current: the commons project is not cleaned, only the webservice
project. Otherwise behavior as above.
should do: I'm not sure. Should commons be cleaned or not?
4.)
root> gradle compile
current:
does compile, test and uploadLibsInternal on commons (due to the fact
that it is a dependency of webservice)
does compile on webservice
should do: should only do compile and uploadLibsInternal on common
5.)
root> gradle clean compile
current:
does clean, compile, test and uploadLibsInternal on commons (due to
the fact that it is a dependency of webservice)
does clean and compile on webservice
should do: The clean behavior is as wanted. But as above Gradle
should only do compile and uploadLibsInternal on common
------------------------------------
I'm wondering if we can solve this by working on our 'skipping'
design. We could define monitors for our projects. The Java plugin
could add a HaveBinariesChanged monitor. Tasks could associate
themselves with those monitors. For example the HaveBinariesChanged
monitor would be used by the test and archive tasks (of course the
archive tasks would use it in conjunction with checking if archives
exists). That shouldn't be that hard to implement and would be a big
step forwards for Gradle multi-project builds. It does not solve the
clean issue of use case 3.). There is another thread from quite a
while ago were we have discussed this issue (Thread Name: dependency
layer refactoring).
What do you think?
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
