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 > ourselves up for trouble here, though? Absolutely 8-) > If a task needs actual Files, for whatever reason... it calls > FileUtils.copyFile, FileUtils.copyResource using new getInputStream() in Resource. > it passes filenames to another class or executable... then we have > to check that we are not dealing with ZipEntries, right? Yes. > Also, you have the fact that Resource names are often going to be > relative, so we would have to add the basedir into the Resource in > order for a standalone Resource to be meaningful, or convert every > Resource to absolute form, which still doesn't catch the > ZipEntries... Yes, I know. Honestly I haven't thought through all the consequences and most tasks we have really make sense for files only. 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 resolve them to an absolute path. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
