Hans Dockter wrote:
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.
We include the java classes from gradle-core in the groovydoc. We should
either not include any java classes in the groovydoc, or include all
java+groovy in the groovydoc. I think we should include everything in
the groovydoc. As the groovydoc tool improves, this could become the
single API reference.
- 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).
Absolutely.
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).
I don't think a separate project is the right way to go. These things
are part of the core project, just like the API is.
I think it's a pretty common pattern for a project to publish a set of
test fixtures to help clients of the project write tests for their
classes. We should build this concept into the Java plugin. Something
like: A java project may provide any of the following to other projects:
- An API
- An implementation of that API
- A test fixture API
- An implementation of that API
You could generalise this: A java project has a number of source sets.
Each source set may have an API and an implementation.
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.
That is true.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
