Paul Speed wrote:
I'm running a recent 0.9.0 nightly build and I'm finally trying to
port over my full release targets from my multi-project builds.
Basically, a zip with all of the project jars, a tarball with all of
the sources, and a javadoc zip with all of the javadocs. The usual
stuff.
I've started with the javadoc task as it seemed to be the one that
would give me the most trouble... and it has.
My project tree consists of one root build.gradle file that injects
some configuration into its children and then several child
directories with their own build.gradle files (pretty typical). Each
child is building out of the same source tree and is using
includes/excludes to manage this in the sourceSets.
The root build.gradle file does not usePlugin('java') (but the
children)... this seems to mean that none of the javadoc defaults are
setup and it complains about missing configuration. For example, I
get an error that optionsFile has not been set and I have no idea how
to make that stop.
This is a bug, that the optionsFile must be specified. It needs to point
to a location where the task can write a temporary file, something like
javadoc {
optionsFile = 'build/tmp/javadoc.txt'
}
The file does not have to exist or contain anything - the task generates
it then passed it to the javadoc executable.
Still, the bigger issue is that the configuration of my root javadoc
task is happening before the configuration of the children. This
seems to mean that my sourceSets filters have not been configured yet
so I end up getting the entire source tree rather than just the
sub-directories and files that make up the modules I'm trying to
distribute.
Here is the broken configuration I'm using cobbled together from
various sources:
task alldocs(type: Javadoc) {
title = "My Project"
destinationDir = new File(project.buildDir, 'docs/javadoc')
subprojects.each {subproject ->
subproject.sourceSets.each {sourceSet ->
source sourceSet.java
}
}
You're also including the test classes to be documented. Is that your
intention?
The above should work fine, regardless of the order that the subprojects
are evaluated. It certainly works for Gradle's build.
Perhaps start with double checking the include/exclude patterns are
actually working - do the jars for each subproject contain the correct
classes? Also, try executing the javadoc task from some of the
subprojects (it should already be there if you're using the java
plugin). Does the result contain the correct classes for that project?
subprojects.each {subproject ->
if( classpath )
classpath += subproject.sourceSets.main.classes +
subproject.sourceSets.main.compileClasspath
else
classpath = subproject.sourceSets.main.classes +
subproject.sourceSets.main.compileClasspath
}
}
I'm sure there are lots of problems with that but the big one right
now is that each sub-project's sourceSet.java includes all files in my
tree.
I grabbed the classpath spec from the docs somewhere but it also
doesn't include any of the compile time jars in it... which I think is
right. My guess is that I need to use the compile configuration
instead of compileClasspath there. But I haven't gotten to that
problem yet.
...and anyway, while that would try to run and just generate too many
javadocs, it doesn't run because of the error about the missing
optionsFile.
Thanks in advance for any help... been poking at this one longer than
I care to say. :) I figure there's something simple I'm missing.
I think we're missing a plugin or two. This is such a common thing to
do, it really needs a plugin to simplify it. For example, we might add a
plugin which aggregates a set of projects (eg subprojects) into a
distribution with javadoc, source, runtime dependencies, and so on.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
