On 11/02/10 12:26 AM, merscwog wrote:
Whether I've done the correct thing or not, I found another way that worked
for me (before I read your post unfortunately) I decided to dig into the
individual javadoc tasks for the subprojects so I never touch configurations
directly anymore.
task alljavadoc(type: Javadoc) {}
def depTasks = []
subprojects.each
{
Project subproject -> depTasks.add(subproject.classes)
}
alljavadoc.dependsOn depTasks
alljavadoc.doFirst()
{
Javadoc task ->
task.project.subprojects.each
{
task.source = task.source + subproject.javadoc.source
task.classpath = task.classpath + subproject.javadoc.classpath
}
}
I can honestly say that I would have never figured out what you've proposed
with the subprojects.inject([]) as I'm not quite sure what that does.
Collection.inject() is a Groovy thing. Have a look at
http://groovy.codehaus.org/groovy-jdk/ which describes all the excellent
stuff that Groovy adds to the standard JDK classes. The example just
collects up the set of compile configurations from the subprojects, and
wraps them in a FileCollection. This might make it clearer (or maybe not):
Closure subProjectCompileConfigs = {
List configs = []
subprojects.each { subproject ->
if (subproject.configurations.findByName('compile') {
configs << subproject.configurations.compile
}
}
return configs
}
alljavadoc.classpath = files(subProjectCompileConfigs)
Calling files() with a closure returns a FileCollection which calls the
closure when the file collection's contents are queried. This way, we
create a placeholder for the classpath, and defer actually calculating
the classpath until the Javadoc task needs it.
BTW, is "<<" still equivalent to doFirst() in your javadocClasspath example?
Yes.
I recall reading that the "<<" style might be removed in the future.
Personally, I think we should get rid of it. I don't think the benefit
we get from conciseness is worth the price we pay in confusion. In fact,
I think we should get rid of actions altogether, and make everything a
task. I think this simplifies things as there is only one concept, not
two. In your build script, you only ever configure a task. Plus, all of
the goodness of tasks (dependencies, incremental building, skipping,
plus future stuff like parallel execution, etc) are available for what
are currently actions. We would make it easier to wire groups of tasks
together so you don't lose the simple dsl that doFirst() and doLast()
provide for defining a sequence of actions.
Regardless, I don't think anyone's planing on changing any of this for
the Gradle 0.9 release. After that we can decide what to do with actions
and the tasks. Also, if we did make changes, we would deprecate the
existing behaviour and leave it in for a few releases.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
