On Aug 22, 2009, at 12:58 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Aug 18, 2009, at 6:02 AM, Adam Murdoch wrote:
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')
}
Do you think we should keep the concept of AntBuilder awareness
once we have gone to native implementation of archives (as far as I
know the only use of this)?
We still need it for the checkstyle and codenarc tasks. We will also
use it soon for the compile and groovy compile tasks (so that we
don't have to unpack all the source dirs and include and exclude
patterns and so on as separate parameters). I'd say in general, we
want to provide an easy way to pass a (potentially complex or
polymorhpic) set of files to an Ant task, regardless of whether
Gradle itself needs to or not.
This makes sense to me.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
