On Jul 19, 2010, at 2:32 AM, Adam Murdoch wrote:
> On 17/07/10 12:05 AM, Levi Hoogenberg wrote:
>>
>> Hello,
>>
>> I've just upgradled my build file to 0.9-preview-3 and I ran into some
>> problems with the copy spec's from method. I've got a working build again,
>> but it would be nice if someone could answer the following questions:
>> Should
>>
>> from(someDir).include('**/*.java')
>>
>> have the same effect as
>>
>> from(someDir) {
>> include '**/*.java'
>> }
>>
>> ? (For me it doesn't, so I'm sticking to the second form ATM.)
>
> They won't necessarily do the same thing. Calling from(someDir) adds someDir
> to the set of source for the copy spec and returns the spec. Calling
> from(someDir) { ... } creates a child copy spec and configures it using the
> provided closure.
>
> So, for example:
>
> from 'a'
> from('b').include('**/*.java')
>
> this includes '**/*.java' from 'a' and 'b'
>
> from 'a'
> from('b') { include '**/*.java' }
>
> this includes everything from 'a', and only '**/*.java' from 'b'
>
> Looking at the first example, I wonder if from() should always create and
> return a child copy spec, because the code certainly looks like you want
> everything from 'a' and only '**/*.java' from 'b'. But then, what should
> something like this do:
>
> from('a').from('b').include('**/*.java')
>
> Not sure. I think I prefer having every form of from() create a child spec.
>
I agree that there is some confusion here, but I'm not sure that changing all
forms of from to create a child spec is the best answer. This needs some more
thought.
The CopySpec was originally intended to support three different forms of
configuration:
A. Fluent style -
copy {
from('a').include('**/b').into('c')
}
This is currently broken - see http://jira.codehaus.org/browse/GRADLE-1044.
I'm looking into it.
B. Nested CopySpecs -
copy {
into 'dest'
from ('a') {
include '**/*.a'
}
from ('b') {
include '**/*.b'
}
}
C. Simple style (which I had thought might be the most common use)
copy {
from 'src'
into 'dst'
include '**/*.java'
}
All the configuration of the simple style was done on the root spec (after
Adam's recent change it all works on a main spec).
It's not just from with a closure that creates a child spec, however. The into
form that takes a closure also creates a child spec. You can do a nested
CopySpec form like this:
copy {
from 'src'
into ('adest') { include '**/*.a' }
into ('bdest') { include '**/*.b' }
}
In my first implementation of CopySpec, a special addSpec() method was required
to create a child spec. It was changed to only add the child specs when a
closure was used with into or from to try to make the syntax a little cleaner.
If you changed both the from and into methods to always create child specs,
then I think the simple style would be broken. In example C above, you would
get two child specs which both inherit the include, but one of them would have
a source and no destination, and the other would have a destination and no
source.
