I worked for a couple of days on adding copy to FileCollections, but I'm not
going to have time to do what I originally intended. There are a couple of issues:
1) FileCollections in general don't have access to an appropriate FileResolver
to resolve the relative paths that might be used as the destination of a copy.
I handled this in FileSet by making a Project.fileSet method (like the files
method). It could construct a FileSet with the project's FileResolver. Changing
the path of construction for all the other types of FileCollections was more
involved and I don't have time right now.
2) Copying a FileCollection generically is a little difficult just because of
the nature of the FileCollection interface. I think this interface may need to
work a little differently to have these collections combine and nest properly.
For example:
def fs= fileSet(from:'src', include:'**/*.java')
fs.copy(into:'dest')
You would expect this to copy a tree from under 'src' to a tree under 'dest'.
If you copy a general FileCollection, however, it will be flattened into the
destination:
files('src/a.java', 'src/org/gradle/b.java').copy(into:'dest')
What would you expect if these were combined?
files('src/a.java', 'src/org/gradle/b.java', fs).copy(into:'dest').
I would like to be able to copy the tree structure from the FileSet into the
destination even if it is accessed as part of a FileCollection, but I'm not sure
how to accomplish this now. It needs some more thought, so I am going to shelve
some of the changes I made to work towards this.
I do have a working implementation of FileSet.copy, but I don't know how useful
that would be. You can already do the same things with AbstractProject.copy.
Should I check this in?
I would like to make AbstractProject.copy official and move it up to Project.
Is this OK?
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
