On 21/07/10 10:24 PM, Steve Appling wrote:
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:
1. 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.
I wasn't thinking we would change into() to create a child spec. So, in
that case, the above examples would be fine.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
