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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
