Steve Appling wrote:
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).
I think we should do this, regardless of what we do with copy. Any
chance you could check that in?
I think we need to work on our terminology:
- A FileCollection is really a set of files. I called it FileCollection
because FileSet was already taken.
- A FileSet is really a hierarchy or tree of files. We called it a
FileSet because Ant does.
- I recently added a FileTree interface to represent the concept of a
file hierarchy. I'm not really happy with this name.
I wonder if we should:
- Rename FileCollection to FileSet
- Rename Project.fileSet() to fileTree() or even tree()
- Move what is FileSet into the internal packages and rename it to
DefaultFileTree
- Do something with the name of FileTree
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.
In this instance, something like: PathResolvingFileCollection.copy()
should delegate to the copy() method of any nested FileCollections it
contains. Similarly, CompositeFileCollection should do the same, and
FileSet should have its own copy() method which maintains the hierarchy.
Or, more generically, move the visiting from CopyActionImpl to
FileCollection, and do something like the above for the various visit()
implementations (I think this would be really useful).
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?
I think so.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
