Adam Murdoch wrote:
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?
For now. I'll want them in the source distribution I think so I might
as well figure it out now.
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?
Yeah, all of that is working fine as I have my various jar, sources.jar,
and javadoc.jar all posting to maven and they only have what they are
supposed to have.
Here's my theory on what is happening... verified by putting prinlns in
my root build.gradle's alldocs task and one of my child projects at the top:
-root build.gradle loads and configures its tasks
-child build.gradle files load and configure their tasks including
setting up includes, source roots, etc.
The problem is that when the alldocs task in root/build.gradle is
configured (and when the above 'each' loop runs) my child projects
haven't had a chance to setup their includes and excludes yet.
I put a println in the alldocs tasks and I definitely see that before
the println at the top of my first child project. So it all makes
sense... I just don't know how to get my child projects to configure
themselves before the alldocs task configures itself.
Note: that projects that include all of their .java files wouldn't
notice this since each subproject would include everything in the
main/java tree over and over. In my case, I have sections of my tree
that I don't want in my all- distros and they are definitely showing up.
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.
Yeah, that would be nice. On my wish/to-do list is an extended maven
plug-in that includes -sources and -javadoc jars... and includes the
local .m2 cache by default. And something to handle whole project
downloadable distros like this would be nice also.
-Paul
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
