ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@m64.com>
Subject RE: Fixes for org.apache.tools.ant.taskdefs.Javac and org.apache.tools.ant.Project
Date Sun, 14 May 2000 16:14:06 GMT
>
>
> Appended to this note are fixes for two related Ant bugs:
>
> BUG 1 - Project.translatePath()
>
> 1. org.apache.tools.ant.taskdefs.Javac uses Project.translatePath() to
> convert various paths to native format (i.e., Unix to Win32, etc.).  But
> Project.translatePath() does not always correctly handle Win32 paths with
> forward slashes, converting for example
>
>    d:/jdk1.3/jre/lib/ext
>
> to
>
>    d;\jdk1.3\jre\lib\ext
>

But paths with forward slashes and a drive letter are not strictly Win32
paths. If you are going to have an absolute Win32 path, why not just use
backslashes (the win32 convention). The code there today
(Project.translatePath()) currently handles C:\blah\blah or even
c:\blah/blah without any problems.

Your heuristic will decide that all single letter paths are Win32 paths
which may not be a good choice. Your approach to converting an absolute
Win32 path to a Unix path will rarely result in a useful path.

Some strings may not be purely win32 or Unix. They may be the result of
combining two properties, once of which is an absolute stub, the other a
relative directory. You may conclude that the resulting string is Win32, and
on a Win32 platform make no translations. That won't matter most of the time
since the File class is forgiving, but I think the result of translatePath
should be a valid path specification for the native platform.

Cheers
Conor


Mime
View raw message