Stefan Bodewig wrote:
As for relative vs. absolute this is a problem anyway.
Mappers need relative names in many places, so if the iterator
returned Files instead of Strings they'd need a way to get back to the
relative name - and if it was String many tasks will need a way to get
the basedir to re
On Thu, 10 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> Just to be clear, I'm talking about the existing
>> oata.types.Resource here which already gets used by zip family of
>> tasks.
>
> Yeah, not a bad idea. Do you think we are setting
> o
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Mar 2005, Stefan Bodewig
> <[EMAIL PROTECTED]> 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.
On Thu, 10 Mar 2005, Stefan Bodewig <[EMAIL PROTECTED]> 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
---
An iterator would be nice.
It would be useful to deal with very large number of
files.
Currently tasks like 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 instre
On Wed, 9 Mar 2005, Matt Benson <[EMAIL PROTECTED]> 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
On Wed, 9 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> public interface FileCollection {
> public (String or File?)[] getFiles();
> }
maybe even Resource[]? That would capture ZipFileSet in a clean way
as well.
> I think it is sufficient to require the type selector's use to
> restric
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 09, 2005 4:13 PM
> > To: Ant Developers List
> > Subject: FileCollections WAS FileSets with
> optional basedir and
> absolute
> >
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 09, 2005 4:13 PM
> To: Ant Developers List
> Subject: FileCollections WAS FileSets with optional basedir and
absolute
> paths for includes
>
> Right now I am leaning toward:
>
> public interfac
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
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > > I'm -0 then. --DD
> >
> > Now what are you? :)
>
> I'm a pain, as usual ;-) It all sounds good Matt.
>
> You know as well as I do that -0 just means I'm
> not fond of the concept, but that y
--- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
wrote:
> I think it should return a List of file descriptors:
>
> interface FileDescriptor {
> InputStream open();
> String getName();
> }
Since it is a FileCollection we are talking about, it
probably makes sense that it should return
> From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
>
> I think it should return a List of file descriptors:
>
> interface FileDescriptor {
> InputStream open();
> String getName();
> }
>
> In that case it will also support file lists, files from a zip, or
> , and it will be pos
I think it should return a List of file descriptors:
interface FileDescriptor {
InputStream open();
String getName();
}
In that case it will also support file lists, files from a zip, or
, and it will be possible to put a mapper inside a fileset.
- Alexey.
Matt Benson wrote:
Okay, the
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> > I'm -0 then. --DD
>
> Now what are you? :)
I'm a pain, as usual ;-) It all sounds good Matt.
You know as well as I do that -0 just means I'm
not fond of the concept, but that you could go
ahead with it. I avoid -1s because I'm mostly
talking her
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > On Wed, 9 Mar 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> >
> > >> Then we could add another implementation of
> FileCollection that's
>
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Wed, 9 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
> >> Then we could add another implementation of FileCollection that's
> >> much like FileSet but doesn't require a basedir.
> >
> > The
On Wed, 9 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> Then we could add another implementation of FileCollection that's
>> much like FileSet but doesn't require a basedir.
>
> Then wouldn't it still be easiest to extend AFS and move the
> "d
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 9 Mar 2005, Dominique Devienne
> <[EMAIL PROTECTED]> wrote:
>
> > I agree with Peter. I don't like this.
>
> Me too.
>
> > Just create such a new type, like ,
>
> "just" 8-)
>
> My idea I never found time to follow through is a
> FileColl
On Wed, 9 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> I agree with Peter. I don't like this.
Me too.
> Just create such a new type, like ,
"just" 8-)
My idea I never found time to follow through is a FileCollection
interface implemented by AbstractFileSet and FileList - and then
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
[SNIP]
> I'm all for a true File Set datatype with no
> basedir,
> but not for retrofitting FileSet into this concept.
>
> Just create such a new type, like , which
> accepts nested filesets if you want, and adapt tasks
> can that conceptually deal
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> --- Peter Reilly <[EMAIL PROTECTED]> wrote:
> > The fact that a fileset has a directory base is I
> > think its basic design.
>
> I like mappers, don't get me wrong, but I have the
> general feeling that different tasks may not always
> use them the
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> I think that this is more fundamental that modifing
> a number
> of tasks.
>
> The fact that a fileset has a directory base is I
> think its basic design.
>
> It is used *a lot* for mappers, in-fact without the
> base-dir
> for the filesets, most uses
I think that this is more fundamental that modifing a number
of tasks.
The fact that a fileset has a directory base is I think its basic design.
It is used *a lot* for mappers, in-fact without the base-dir
for the filesets, most uses of mappers by tasks make no sense.
Peter
Matt Benson wrote:
Time
I'm all for making File*Set* actually be capable of a true set of files
anywhere I choose. The basedir restriction is one of the single
biggest walls I hit and workaround. So, +1 from me.
Erik
On Mar 8, 2005, at 6:45 PM, Matt Benson wrote:
Time for controversy! There is an interesting
Time for controversy! There is an interesting thread
at
http://issues.apache.org/bugzilla/show_bug.cgi?id=5035
that touches on this issue. The key issue was that
some tasks (including 3rd party ones) would break if
AFS.getDir() were to return null. This is indeed
true. I have implemented the su
26 matches
Mail list logo
