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.

BTW, is "<<" still equivalent to doFirst() in your javadocClasspath example? 
I recall reading that the "<<" style might be removed in the future.

Thanks for the solutions.

-Spencer


Adam Murdoch-2 wrote:
> 
> To fix the problem, you could move the doFirst() action to a stand-alone 
> task:
> 
> task javadocClasspath << {
>     subprojects { ... do stuff to configurations.compile ... }
> }
> 
> task alljavadoc(type: Javadoc, dependsOn: javadocClasspath) {
>      ....
> }
> 
> Or you could build the dependencies on demand in the javadoc task (this 
> has the advantage that the task dependencies are automatically wired up 
> for you):
> 
> task alljavadoc(type: Javadoc) {
>      classpath = files {
>          subprojects.inject([]) { classpath, subproject ->
>              if ( subproject.configurations.findByName('compile') ) {
>                  classpath << subproject.configurations.compile
>              }
>              // don't need to worry about providedCompile - it will be 
> included in compile.
>              classpath
>          }
>      }
> }
> 

-- 
View this message in context: 
http://old.nabble.com/StackOverflow-with-latest-0.9-snapshot-from-Feb-02%2C-2010-tp27475547p27531095.html
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to