Re: [gradle-dev] api for tasks which take source as input

[Adam Murdoch]

John Murph wrote:
On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <a...@rubygrapefruit.net 
<mailto:a...@rubygrapefruit.net>> wrote:

    Hi,

    I'm reworking the API of the various tasks which take source as
    input, so they can handle our various types such as FileCollection
    and FileTree. This includes the tasks: Compile, GroovyCompile,
    ScalaCompile, Javadoc, Groovydoc, Scaladoc, Checkstyle, CodeNarc.

    I'd like to keep the ability to keep the ability to use a source
    directory or set of source directories. So, I'm thinking something
    like the following, instead of the srcDirs property:

    void src(Object... source)  // Interprets source as per
    CopySpec.from(source):

    void setSrc(Object source) // Equivalent to discarding all the
    current source and calling source(source)

    FileTree getSrc() // Returns the tree of source.

    Plus all the methods on PatternFilterable: include(), exclude(), etc.

    Some examples:

    compileJava {
      src 'src/main/java' // includes all files under
    $projectDir/src/main/java
      src 'src/java/Source1.java', 'src/java/Source2.java'  //
    includes the 2 specified source files
      src ['src/main/java', 'src/Source1.java']
      src source.main.java // all java source in the 'main' source set
      src { javaSrcDirNames.collect { "$srcRoot/$it" } } // 0.7 behaviour

      include 'org/gradle/api/**'
    }

    and you can do things like:

    copy {
      from compileJava.src
      into 'some/dir'
    }


Sounds good.  Of course, I more often want to manipulate (e.g. copy) 
the output than the source, but I assume that's coming.

You can already do that:

copy {
   from compileJava.destinationDir
   into 'some/dir'
}

 

    Some questions:

    - Should we call the method from() instead of src(), to be
    consistent with the Copy task?


I think either would be O.K., but using src seems more clear to me 
than from.  Although, the line "src source.main.java" seems a bit 
redundant.

Indeed, given that this is the default. It's just an example to 
demonstrate the goodness we get from replacing srcDirs property with the 
more general src property. Perhaps some better examples are:

compileJava {
   src fileTree('some-file.zip')  // compiles all source files found in 
some-file.zip
   src remoteFileTree('http://some-repo/some-file.zip')
   src vcsFileTree('g...@github.com/some-repo/src/main/java')
}

 

    - Do we need the include and exclude methods on these tasks?
    Source set has them, as does FileTree, so you can do:

    source.main.java {
      include 'some/pattern/**'
      exclude 'some/other/pattern/**'
    }

    or

    compileJava {
      src fileTree {
          from 'some/src/dir'
          include 'some/pattern/**'
          exclude 'some/pattern/**'
      }
    }


I think we should have the include and exclude methods on the tasks.  
The FileTree approach would be fine if we thought it was an unusual 
need to specify includes or excludes, but I don't think that it is, 
esp. for those coming from Ant based projects.


We do want to encourage people to specify their includes and excludes on 
the source set, rather than the individual tasks. This way they are 
shared by all tasks, including any new ones we add. One way to do this 
is remove the patterns from the tasks.


Adam