stefan, what you say makes sense, now based on your description on how things work, shouldn't the Ant.setAntfile(String) method be changed to Ant.setAntfile(File) ?
thxs. a Stefan Bodewig wrote: > On Tue, 04 Sep 2001, Alejandro Abdelnur <[EMAIL PROTECTED]> > wrote: > > > i've run into a similar problem in the ant's antfile, the problem > > appears to be a bug in the java.io.File.isAbsolute() method in the > > windows platform. > > Judging from your patch I assume that you think File.isAbsolute() > should return true for \temp on Windows, right? > > From the javadocs of File: > > >> An absolute pathname is complete in that no other information is > >> required in order to locate the file that it denotes. > > with this definition, I think you are wrong. > > A completely different issue is whether FileUtils.normalize() should > treat \temp the same way it treats an absolute path (it does) - I'm > not sure as I cannot really see all consequences here. > > In which situation would a Windows user (I'm not part of that > community, so I don't really know) use \temp instead of C:\temp? > > > i think the place to add this workaround is the > > FileUtils.normalize() method, > > I think it already treats paths starting with File.separator as > absolute paths. Looks as if <ant> should use > FileUtils.resolveFile(dir, antfile) in its execute method. > > > then the ant.setAntfile() method should be retrofitted to use the > > normalized (similarly any other attribute that expects a file name). > > Most tasks have setters that expect a File argument when they expect > filenames - these setters will receive File instances that went > through FileUtils.normalize (via FileUtils.resolveFile) automatically. > > Stefan
