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.
(Just a thought, no criticism or anything.) On Wed, Jul 21, 2010 at 2:24 PM, Steve Appling <[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. >
