Hans Dockter wrote:
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
This is great. It will force us to get multi-project builds working well
for java applications.
Some issues I've seen already:
- The groovydocs don't include anything from gradle-wrapper.
- The javadocs don't include anything from gradle-core.
What we want here, I think, is a single javadoc task and a single
groovydoc task in the root project, whose source is the union of the
source from each subproject. We don't care about the javadoc/groovy doc
from each individual subproject.
- The unit test reports are split up.
I'd like a single, unified test report. This will also be true of a code
coverage report. And probably all of the code quality reports.
- The wrapper task is still in gradle-core.
This belongs with the rest of the wrapper stuff. Otherwise we've got an
awkward runtime coupling between the 2 modules (a cyclic dependency, no
less). It would be better if gradle-wrapper depended on gradle-core at
compile time (ie Wrapper task is in gradle-wrapper), as this makes the
dependency both explicit and non-cyclic.
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 should it change, do you think?
How do we want to go from here? Some idea:
root (integtest (including dealing with the integ test sources),
distribution, release
- user's guide
and samples
- gradle-ui
- gradle-wrapper
- gradle-core
- plugins
Shouldn't this be called 'gradle-plugins'? Or should we drop the
'gradle-' bit from the other subproject names? It's doesn't really
provide any information.
The plugins projects should also include the plugin-specific tasks. I
think it's really only Clean, Copy, and Upload which belong in gradle-core.
-- osgi
-- jetty
-- eclipse
-- maven
-- ...
I think splitting each plugin out into separate subprojects is a bit
premature. It feels a bit too fine-grained, a bit too early. I would
prefer we just moved all the plugins and plugin-specific tasks into a
single 'gradle-plugins' subproject. We can split it later.
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.
It would be nice if Gradle understood the concept of a verification
task, such as 'test', 'checkstyle', 'integTest', etc. Then, it could
schedule them in order from fastest to slowest (based on the history of
execution time). Maybe it should do this for all tasks, subject to the
dependsOn constraints, of course.
Also, it feels like we're missing a plugin which takes care of
aggregating a bunch of java projects into a single project, which is
basically what the root project build is currently doing.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
