I have just submitted a new build structure for the Gradle build. The
Gradle build is now a multi-project build with a root project and two
subprojects.
root
- gradle-core (which contains everything except wrapper)
- gradle-wrapper
ATM root is doing user's guide, distribution, release and integtest.
The integtest are still part of gradle-core but executed from root.
Although this shows the enormous flexibility of Gradle it probably
should not remain like this.
How do we want to go from here? Some idea:
root (integtest (including dealing with the integ test sources),
distribution, release
- user's guide
- gradle-ui
- gradle-wrapper
- gradle-core
- plugins
-- osgi
-- jetty
-- eclipse
-- maven
-- ...
There are a couple of other possibilities to split things up. What are
your thoughts?
Another issue is that client modules don't work within a multi-project
build yet. Therefore I have flattened the dependency declaration in
the gradle-core build. As soon as client modules work in multi-project
builds, I will put the client modules back into the gradle-core build.
The order in which the tasks currently are executed is a bit awkward.
If you do 'developerBuild' the integtest for the distribution is
executed before the unit tests of gradle-core.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
