On Aug 22, 2009, at 12:03 AM, Adam Murdoch wrote:
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.
I think as long as the Groovydoc is not a replacement for javadoc we
might not include any java classes. It is quite a big one to upload
when you do a release. Considering the fact that in particular our
public API will contain less and less groovy classes, I'm not sure if
we should move away from the very robust javadoc.
- 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
I agree. I like this much more. This will avoid a lot of the bloat you
often find in Maven multi-project builds.
You could generalise this: A java project has a number of source
sets. Each source set may have an API and an implementation.
Cool.
<snip>
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
