John Murph wrote:
On Mon, Sep 21, 2009 at 6:03 PM, Adam Murdoch <[email protected]
<mailto:[email protected]>> wrote:
John Murph wrote:
On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch
<[email protected] <mailto:[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.
This is a nifty idea.
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
<mailto:[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.
I prefer source over src. The problem with source is that it clashes
with the source property on project. You'd have to do something like
compileJava {
source project.source.main.java
}
But then, given that the above is the default, maybe we don't care.
Adam
