You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matt Benson <gu...@yahoo.com> on 2005/03/09 23:13:24 UTC
FileCollections WAS FileSets with optional basedir and absolute paths for includes
Right now I am leaning toward:
public interface oata.types.FileCollection {
public Iterator iterator();//of Files
}
This should have the added benefit of built-in support
in ac:for, though I suppose wrapping in a path would
work as well. Incidentally, should Path not implement
FileCollection?
I still need a name for "an absolute collection of
files" that is hopefully short enough to make a usable
XML element name a la FileSet, and am eagerly awaiting
suggestions.
Thanks,
Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: FileCollections WAS FileSets with optional basedir and absolute
paths for includes
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 10 Mar 2005, Stefan Bodewig <bo...@apache.org> wrote:
> Resource instead of File could be even better.
Just to be clear, I'm talking about the existing oata.types.Resource
here which already gets used by zip family of tasks.
We may even add a getInputStream method to it ...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: FileCollections WAS FileSets with optional basedir and absolute
paths for includes
Posted by Peter Reilly <pe...@apache.org>.
An iterator would be nice.
It would be useful to deal with very large number of
files.
Currently tasks like <copy> store all the files and maps
in memory and then processes the files.
This causes problems like OOM exceptions when dealing
with large directories.
A url or resource would also be nice instread of File or String.
Peter
Stefan Bodewig wrote:
>On Wed, 9 Mar 2005, Matt Benson <gu...@yahoo.com> wrote:
>
>
>
>>Right now I am leaning toward:
>>
>>public interface oata.types.FileCollection {
>> public Iterator iterator();//of Files
>>}
>>
>>
>
>Iterator works for me, but so would an array. We do have some cases
>where we only want to check whether a collection is empty, the
>resulting on-liner may be easier to read with an array.
>
>Resource instead of File could be even better.
>
>
>
>>I still need a name for "an absolute collection of
>>files" that is hopefully short enough to make a usable
>>XML element name a la FileSet, and am eagerly awaiting
>>suggestions.
>>
>>
>
>I like DD's suggestion of <files> as well.
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: FileCollections WAS FileSets with optional basedir and absolute
paths for includes
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 9 Mar 2005, Matt Benson <gu...@yahoo.com> wrote:
> Right now I am leaning toward:
>
> public interface oata.types.FileCollection {
> public Iterator iterator();//of Files
> }
Iterator works for me, but so would an array. We do have some cases
where we only want to check whether a collection is empty, the
resulting on-liner may be easier to read with an array.
Resource instead of File could be even better.
> I still need a name for "an absolute collection of
> files" that is hopefully short enough to make a usable
> XML element name a la FileSet, and am eagerly awaiting
> suggestions.
I like DD's suggestion of <files> as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org