This is what I use and it still works with preview 3:
task alldocs(type: Javadoc) {
title = "My Project version $version Project API Documentation"
destinationDir = new File(project.buildDir, 'docs/javadoc')
optionsFile = new File( 'build/tmp/javadoc.txt' )
subprojects.each { subproject ->
source subproject.sourceSets.main.java
if( classpath )
classpath += subproject.sourceSets.main.classes +
subproject.sourceSets.main.compileClasspath
else
classpath = subproject.sourceSets.main.classes +
subproject.sourceSets.main.compileClasspath
}
}
Note: I do have to do some funkiness to work around classpath being null
in the initial pass but source works like one might expect.
I don't know if there is a simpler gradle way to do this (and I've tried
a few simpler approaches.)
-Paul
Philip Crotwell wrote:
When you get this working, could you put something about how into the
cookbook? I think common javadocs for a mulitproject sounds like
something others, myself included, might need to do as well.
http://gradle.codehaus.org/Cookbook
thanks,
Philip
On Fri, Jun 4, 2010 at 12:15 PM, Spencer Allain
<[email protected] <mailto:[email protected]>> wrote:
I'm playing with the infamous all-subprojects javadocs again, as my
original changes for 0.9 ceased to function with preview release 3.
Arguably, I was not doing things the correct way in the first place,
but it was interesting to discover why it no longer works.
alljavadoc.doFirst()
{
Javadoc task ->
task.project.subprojects.each {
Project subproject ->
task.source = task.source + subproject.javadoc.source
task.classpath = task.classpath + subproject.javadoc.classpath
}
}
Now I get "Cause: Cannot invoke method plus() on null object"
Not sure if this is a DSL or groovy version change, or what.
Anyway, in attempting to find a uniform way of adding to the values,
it seems that source and classpath are both set to null objects (at
least as visible via the implicit get() methods).
Is there a reason that list-type objects are initialized to null (or
in the case of source within SourceTask made to appear to be null)
instead of treated as empty collections? I suspect it might be for
performance reasons, or maybe just a style reason, but it seems
inconsistent with many other collections that are initialized to
empty instead of null.
-Spencer
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
