Steve Appling wrote:
Adam Murdoch wrote:
Steve Appling wrote:
I have updated the copy branch.
Completed:
* Unit tests for BreadthFirstDirectoryWalker and CopyVisitor
* Fixed error path for CopyVisitor and CopySpecImpl.filter()
* You can use single files (not just directories) as sources. I
did not make
a special attribute for a single target with a rename.
* Changed the signature of the CopySpec.from methods to work like (and
delegate to) Project.file
* Removed CopySpecImpl's use of Ant
* Changed PatternMatcher to Spec<RelativePath>
This all looks good. I'll apply it to the trunk if you think it's ready.
I'm still not sure about adding Project.copy(). It feels out of place
there. Maybe a better place for it would be on File and/or
FileCollection.
I'm not really sure what to do about this either. There are a lot of
subclasses of FileCollection (including Configuration which already
has a copy). I think this would be confusing here.
FileCollection simply represents the things you can do to a collection
of files. Being able to copy them somewhere makes perfect sense. We
might have, for example, something like:
configurations.compile.copy(into: 'build/dists/exploded/libs')
configurations.compile.copy { into: 'somedir'; exclude {
it.isDirectory() }; rename { ... } }
files('a', 'b').copy(into: 'build/libs')
new FileSet(dir: 'src', includes: ['**/*.java']).copy(into: 'build/src')
And for file:
file('some.xml').copy(into: 'build/somedir')
file('some.xml').copy { into 'build/somedir'; replaceTokens(...) }
This could then grow into a decent file manipulation DSL (on top of the
goodness that Groovy already provides)
Adding Project.copy() has a couple of problems, I think:
- Project gets bigger. We want to be careful not to keep adding stuff to
Project, just because it's there.
- Copying doesn't really have anything to do with projects. It belongs
somewhere better related to file operations. It also belongs somewhere
that is usable when you don't have a project, and outside the build script.
Adding copy operations to FileCollection and File is one way to address
these problems.
Do you think that it is useful to be able to access other Tasks in a
similar way?
I think it would be useful to be able to use the operations that some
tasks also happen to use. I don't think it's a good idea to use them as
tasks.
Should you be able to use tasks.copy { } or tasks.zip { }?
No. But you should be able to easily write code which can copy, move,
zip, unzip, tar, etc files. That code could be in a build script, a
plugin, a custom task, a library class, or internal to Gradle. It could
be Groovy or Java.
Again, adding these operations to FileCollection and File solves this
problem. Adding them to Project does not.
I can write a little more about the copy task in the userguide if you
think it is needed.
That would be good.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
