Agreed. If no one has the itch, we should shelve it. I would just list it as: Not going for 1.0 and we wouldn't include it in the 1.0 tag. It can stay in its current place in CVS I think. We got away with this a lot in Lang, having packages that didn't deploy even though they were in HEAD etc.
Are there any methods in there that are worth pushing? Or just skip the whole thing for 1.0 and when someone turns up with the itch we can hit them with all the difficulties and as a group solve them? Hen On Tue, 30 Dec 2003, __matthewHawthorne wrote: > I agree that it seems like a lot of work. I work primarily on Unix and > can definitely lend a hand, but you may be correct about skipping it for > the 1st release. > > > Jeremias Maerki wrote: > > As announced I'd like to outline how I currently see FilenameUtils. > > Current problems are: > > - Some test cases are disable because they fail. > > - The test cases are incomplete. Some work only on Unix because they use > > slashes and the Windows path separator is a backslash. Another example: > > removeExtension looks for the last occurence of a dot which doesn't work > > as soon as you forget to remove the path before the filename first. > > - Some methods (like normalize) only work on Unix. They use hardcoded > > slashes. > > - Some methods are duplicates and still have to be removed. > > > > I've started to work on that last week but have stopped as I realized > > that we may need to discuss the approach first. FilenameUtils will be > > expected to be written once and run everywhere. :-) So it has to work on > > Unix and Windows (at least). > > > > Sun with their java.io.File framework have special implementations of > > the not quite public java.io.FileSystem class that seems to handle some > > of the platform dependencies. Other things are handled within > > java.io.File where backslashes get converted to slashes internally. > > > > I think we should do that, too. But as in java.io.File there are a few > > nasty things to consider (like UNC and drive-relative paths). I wonder > > if we can handle all that properly without too much effort. I doubt so. > > > > Another question is what to do with Windows-style filenames on Unix and > > vice-versa. What should happen when a UNC path is processed on Unix? How > > to write the test cases? A separate set for Windows and Unix? Should > > FilenameUtil methods return Windows-style paths on a Unix machine if a > > Windows-style path is used as input? If a mix is found (a mix of slashes > > and backslashes) shall FilenameUtils return the platform-specific style? > > > > As I stated before I'm not really a fan of working with String filenames > > so I actually have a rather small motivation to work on this after I > > found out about all the difficulties. I realize I'd rather skip > > FilenameUtils for the initial release. If someone working on Unix is > > really willing to help me (I'm working on Windows) work on FilenameUtils > > then I'm in. But I'm sure it'll take some time until everything is > > stable. If we target a release real soon now, I think we have to skip > > FilenameUtils. > > > > In this area we've had a related thread before (for those who want to > > read that up): > > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=380749 > > > > That thread and the ideas there make this even more complicated. But we > > don't have to do everything now I guess. > > > > Thoughts? > > > > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
