Paul Speed wrote:
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.
As I mentioned before, you shouldn't have to. The Javadoc task is
supposed to evaluate its inputs lazily, that is, when the task executes,
which is after all the projects have been configured. And this works
fine for the Gradle build, and for a test build. So something about your
build is causing this to not work.
Let's try this:
task alldocs(type: Javadoc) {
subprojects.each {subproject ->
subproject.sourceSets.each {sourceSet ->
source { sourceSet.java } // <- note the reference to
sourceSet.java is in a closure
}
}
}
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
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
