api for tasks which take source as input

[Adam Murdoch-2]

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'
}

Some questions:

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

- 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/**'
    }
}


Adam


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

    http://xircles.codehaus.org/manage_email

[John Murph]

On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <a@...> 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.
 

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.
 

- 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.

--
John Murph
Automated Logic Research Team

[Adam Murdoch-2]

John Murph wrote:

On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <a@...> 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('git@...')
}

 

- 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

[John Murph]

On Mon, Sep 21, 2009 at 6:03 PM, Adam Murdoch <a@...> wrote:

John Murph wrote:

On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <a@...> 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('git@...')

}

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

[hdockter]

On Sep 21, 2009, at 11:20 AM, Adam Murdoch 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'
> }
>
> Some questions:
>
> - Should we call the method from() instead of src(), to be  
> consistent with the Copy task?

I'm not sure if consistency is that important here as it is a  
different part of the domain (compared to for example copy/move). src  
is more expressive I think. On the other hand having 'from' as the  
standard method to include file elements make our API easy to  
remember. I'm not sure what the best approach is.

>
> - 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/**'
>   }
> }
>

 From Gradle 0.8 the source set are the elements that usually should  
get configured by the user. Normally you do not want to filter just  
for the compile. You want this filter to be applied also for jar,  
javadoc, ... This is what the source sets offer. So I think specific  
compile excludes/includes are a minor use case we should not bloat our  
API for.

I could not find a way to copy a fileTree. Have I missed something?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:

>
> On Sep 21, 2009, at 11:20 AM, Adam Murdoch 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'
>> }
>>
>> Some questions:
>>
>> - Should we call the method from() instead of src(), to be consistent
>> with the Copy task?
>
> I'm not sure if consistency is that important here as it is a
> different part of the domain (compared to for example copy/move). src
> is more expressive I think. On the other hand having 'from' as the
> standard method to include file elements make our API easy to
> remember. I'm not sure what the best approach is.
>

I think src works pretty well, provided we use it consistently for tasks
that take source as input.

>>
>> - 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/**'
>>   }
>> }
>>
>
> From Gradle 0.8 the source set are the elements that usually should
> get configured by the user. Normally you do not want to filter just
> for the compile. You want this filter to be applied also for jar,
> javadoc, ... This is what the source sets offer. So I think specific
> compile excludes/includes are a minor use case we should not bloat our
> API for.

The use case I had in mind was for people using the tasks without using
the plugin. But they can always construct a file tree to pass in as the
source.

>
> I could not find a way to copy a fileTree. Have I missed something?
>

You can pass pretty much anything to CopySpec.from()

copy {
   from 'some/dir'
   from someDir
   from someFile
   from [someDir, someFile]
   from { someDirsAndFiles }
   from [src: someDir, file: someFile]
   from files(moreDirs)
   from fileTree(dir: yetAnotherDir)
   from source.main.allSource.matching { include 'org/gradle/api/**',
exclude '**/internal/**' } + source.main.classes
   from { someDirsAndFiles } as Callable
   ....
}


Adam


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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

John Murph wrote:

On Mon, Sep 21, 2009 at 6:03 PM, Adam Murdoch <a@...> wrote:

John Murph wrote:

On Mon, Sep 21, 2009 at 5:20 AM, Adam Murdoch <a@...> 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('git@...')

}

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

[John Murph]

On Tue, Sep 22, 2009 at 5:48 PM, Adam Murdoch <a@...> wrote:

<snip>
 

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

I don't mind if the default is a bit confusing, so I would go with source without a better reason.  However, another possibility is to name the property on project 'sourceset'.  This matches the name of the concept in the docs, and reads fine as well. 

compileJava {
    source project.sourceset.main.java
}

Every time I read project.source, I have to mentally translate it to "the project's source set".  If you rename this, then source as the name of the method is not really confusing.  The above means that to compile java it should use the source located in my project's main source set.  The .java ending is noise, however, as I already said compileJava.  Could we do away with that?  Maybe the compileJava task could know that it needs java source?


--
John Murph
Automated Logic Research Team

[hdockter]

On Sep 22, 2009, at 11:21 PM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 21, 2009, at 11:20 AM, Adam Murdoch 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'
>>> }
>>>
>>> Some questions:
>>>
>>> - Should we call the method from() instead of src(), to be  
>>> consistent with the Copy task?
>>
>> I'm not sure if consistency is that important here as it is a  
>> different part of the domain (compared to for example copy/move).  
>> src is more expressive I think. On the other hand having 'from' as  
>> the standard method to include file elements make our API easy to  
>> remember. I'm not sure what the best approach is.
>>
>
> I think src works pretty well, provided we use it consistently for  
> tasks that take source as input.
>
>>>
>>> - 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/**'
>>>  }
>>> }
>>>
>>
>> From Gradle 0.8 the source set are the elements that usually should  
>> get configured by the user. Normally you do not want to filter just  
>> for the compile. You want this filter to be applied also for jar,  
>> javadoc, ... This is what the source sets offer. So I think  
>> specific compile excludes/includes are a minor use case we should  
>> not bloat our API for.
>
> The use case I had in mind was for people using the tasks without  
> using the plugin. But they can always construct a file tree to pass  
> in as the source.
>
>>
>> I could not find a way to copy a fileTree. Have I missed something?
>>
>
> You can pass pretty much anything to CopySpec.from()
>
> copy {
>  from 'some/dir'
>  from someDir
>  from someFile
>  from [someDir, someFile]
>  from { someDirsAndFiles }
>  from [src: someDir, file: someFile]
>  from files(moreDirs)
>  from fileTree(dir: yetAnotherDir)
>  from source.main.allSource.matching { include 'org/gradle/api/**',  
> exclude '**/internal/**' } + source.main.classes
>  from { someDirsAndFiles } as Callable
>  ....
> }

I meant to make a copy of an instance of FileTree. I see now that  
matching is doing exactly what I was looking for. Excellent.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

John Murph wrote:

On Tue, Sep 22, 2009 at 5:48 PM, Adam Murdoch <a@...> wrote:

<snip>
 

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

I don't mind if the default is a bit confusing, so I would go with source without a better reason.  However, another possibility is to name the property on project 'sourceset'.  This matches the name of the concept in the docs, and reads fine as well. 

This is a good idea. I've renamed project.source to project.sourceSets

compileJava {
    source project.sourceset.main.java
}

Every time I read project.source, I have to mentally translate it to "the project's source set".  If you rename this, then source as the name of the method is not really confusing.  The above means that to compile java it should use the source located in my project's main source set.  The .java ending is noise, however, as I already said compileJava.  Could we do away with that?  Maybe the compileJava task could know that it needs java source?

I think this also a good idea. We could add some kind of source set awareness to various tasks, so that, for example, the Test task knows that it should use the classes out of sourceSet.classesDir, and the classpath out of sourceSet.runtimeClasspath. Or the Compile task knows that it should use the source out of sourceSet.java and the classpath out of sourceSet.compileClasspath.


Adam