On Mon, Sep 21, 2009 at 6:03 PM, Adam Murdoch <[email protected]> wrote:
> > > John Murph wrote: > > On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <[email protected]>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' > } > > Yes, but I was thinking more along the lines of an analog to source sets. Like a generic "output" concept that tasks would have. For a compile task, the output is a directory. For a jar task it's an archive. I'm not sure this is necessary or helpful, but it's what I was thinking when I wrote that. The only real complaint I have with the current approach is that every task uses a different name so it can be a pain to track down what to use in a specific instance. > >> 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('[email protected]/some-repo/src/main/java') > } > > I like those examples much more. In that case, I definitely vote for src (or source?) as the method name. > >> - 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. > > Are there any good reasons to use patterns for a specific task? If not, I would rather remove them so as to avoid confusion about the "right way" to do things. -- John Murph Automated Logic Research Team
