I know that some some stuff is a bit rough ATM. I just wanted to
submit it rather quick to avoid merge nightmares as much as possible
(including for myself). But of course everything should work.
On Aug 21, 2009, at 1:49 AM, Adam Murdoch wrote:
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.
It is Java only. That's why the gradle-wrapper should use the Java
plugin only.
- The javadocs don't include anything from gradle-core.
I will look into this.
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.
This is how it is supposed to work. I should have tested it. Which
points out that it might be good to have some tests for our build
(e.g. check that the exploded dist has certain non-empty directories).
But I agree with John, that it should be possible to generate them for
a subproject only (although for the current Gradle build it doesn't
really matter).
- 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.
I have forgotten about those.
- 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.
I know. This will move.
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?
Either the code should go into root or into a separate integtest
subproject. I both cases we face the problem of accessing some test
helper classes (e.g. HelperUtil). We could create our own subproject
for them (So far this is about 2 classes). A simpler alternative at
the moment would be to add the test-classes of gradle-core to the
classpath of gradle-dist:integTest.
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.
We should drop those and just use the prefix for the naming of the jars.
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.
I know that we have discussed this already. I agree that we first
should move the whole lot. But size is I think only one indicator
whether to put something in its own subproject. The other is clear
boundaries. And putting it into single subprojects makes it also much
clearer which plugin needs which dependencies.
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.
Interesting. That sounds like a good idea.
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.
I was thinking the same.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
