Steve Appling wrote:
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.
Not quite sure what you mean here.
FileCollection extends AntBuilderAware, which means every FileCollection
impl is responsible for adding itself to an Ant task. The generic
AbstractFileCollection adds itself as an Ant path, the current FileSet
adds itself as an Ant fileset. FileTrees with multiple base dirs, like
SourceDirectorySet, add themselves as multiple filesets, one for each dir.
One shortcoming with the current AntBuilderAware interface, is that
there is no way for the implementer to know which Ant type the task is
expecting. It would be good if every FileCollection impl could be added
as a path, fileset, or resource collection. Something like:
AbstractFileCollection.addToAntBuilder():
- path: add a path, with the result of getAsPath()
- fileset: copy the collection to a temporary dir and add a fileset
pointing to that temp dir.
- resource collection: as path
CompositeFileCollection.addToAndBuilder():
- path: as above
- fileset: as above
- resource collection: as a resource collection, delegating to each
FileCollection to add itself as a nested resource collection.
FileSet.addToAntBuilder():
- path: as above
- fileset: add a fileset
- resource collection: as fileset
Another good thing would be if AntBuilder understood AntBuilderAware (as
in, was AntBuilderAwareAware :)
ant.sometask {
classpath configurations.compile
source fileset(dir: 'some-dir') + fileset(dir: 'some-other-dir')
}
rather than
ant.sometask {
configurations.compile.addToAntBuilder(ant, 'classpath')
(fileset(...) + fileset(...)).addToAntBuilder(ant, 'source')
}
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
