Adam Murdoch wrote:
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
I would like to see the current FileSet that is needed to represent Ant FileSets
distinct from Gradle FileSets (or FileTrees) which can be used for other
purposes. Currently the Ant FileSets can't have more than one base directory,
so this kept me from using the same type of nested CopySpecs to represent a the
content of a FileSet.
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).
I think that either of these are better approaches than what I originally had in
mind, but I'm not sure I have time right now to pursue it.
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
I checked in two Project.fileSet methods that let you construct FileSets with an
appropriate FileResolver in a couple of ways. I added a copy method to FileSet.
It has a property based, closure based, or fluent variant. See
FileSetCopyIntegrationTest for examples of the three forms.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
