On 21/07/10 10:33 PM, Levi Hoogenberg wrote:
Isn't Gradle trying to be too flexible, then? How many users would
complain if there was only one way of combining the from, into, and
include methods? (Provided that all use cases are covered, of course.)
The more ways Gradle offers to solve a particular problem, the harder
it gets to understand.
This is a good point. One possible solution to reduce complexity is to
get rid of the fluent style. To me, the other styles are naturally
explicit about scoping, by using code blocks to group related things:
copy {
// declarations that apply globally are siblings
from 'src'
into 'dest'
include '**/*.java'
}
copy {
from 'src'
from('otherSrc') {
// declarations that apply only to a single source or
destination are attached to it in a code block
include '**/*.java'
}
into 'dest'
}
whereas, with the fluent style, declarations which are siblings are
artificially attached to each other. This means you can construct some
ambiguous looking expressions. For example, these don't do what the
structure suggests they should:
copy {
into('dest')
from('src')
from('otherSrc').include('**/*.java')
}
copy {
from('src').include('**/*.java').into('dest')
from(otherSrc').into('otherDest')
}
On Wed, Jul 21, 2010 at 2:24 PM, Steve Appling <[email protected]
<mailto:[email protected]>> 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.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
