On Wed, Sep 23, 2009 at 9:44 AM, Thomas Kinnen <[email protected]> wrote:
> Hi everyone,
> is there an easier way to copy files then using ant.copy or a Copy Task?
> The copy task is very verbose for just copying one file to another
> directory. If you want to rename it on the way it gets even more
> complicated.
> Something like project.copy(from, to) would be great. I know it exists in
> the current build, but there you also have to specify a copySpec, so it's
> not really less verbose. project.copy(from: filea, to: fileb) would be
> great. Thereby renaming filea to fileb. Maybe an option would be to make the
> copySpec check if the source is a file and if yes, also treat the
> destination as file(if not yet created as directory). Thereby allowing
> something like
> task test(type: Copy) {
> from: "dir/file1.txt"
> into: "dir2/file2.txt"
> }
>
>
I'm not sure what you mean about the copySpec? That's just an
implementation detail. To use, you would do
task test << {
copy {
from 'dir/file1.txt'
into 'dir2/file2.txt'
}
}
I'm not sure that the into can be a string (we always use a directory as the
into), but the general syntax is as shown. Even better, "from" can take all
kinds of things, making this much more powerful than the ant version.
> When using an ant.copy(from, to) it seems that Gradle is eager evaluating
> it. Therefor it will throw an error message if the file I want to copy is
> not yet available. This seems to be a general problem with ant tasks. If I
> want to copy something from or into the libsDir, ant will complain that the
> directory is not available (which is true at evaluation time). Therefor I
> would have to add an mkdir(dir: libsDir) before each of these tasks(copy,
> jar, etc.). Maybe I am missing something?
>
>
I think the reason it is being eagerly evaluated is because you are using a
configuration closure when defining a task with type Copy. This means the
closure is executed right away. Contrast that with the test task I defined
above, which uses an execution closure. I also think the copy function I
used above creates the output directory on demand (but don't quote me on
that).
Another problem i have encountered is Java Memory out of Heap Space when
> running a compile over a lot of subprojects. I have added the following
> clause to the subprojects closure on my main project:
> compile.getOptions().forkOptions.memoryMaximumSize = "1024m"
> compile.getOptions().fork = true
> Still I get out of heap space errors, so something seems to be wrong.
>
> Other then that it has been a pleasure working with Gradle. Keep up the
> great work.
>
> Thomas
>
>
--
John Murph
Automated Logic Research Team
