Re: Fixes for org.apache.tools.ant.taskdefs.Javac and org.apache.tools.ant.Project

[Eugene Bekker <eb...@powervision.com>]

I think the reason that Perl, Java and the other tools correctly parse the
path c:/path/file is that they do it with the current OS/platform in mind. 
Like Conor pointed out, they have to account for single letter top level
folders.

However, my 2 bits... I maybe missing the point of the discussion a bit,
but I think we have to take a practical look.  The whole point of this is
to have a cross-platform build tool, and thus a cross-platform description
of the build process for the tool.

If you end up putting paths like d:/foo/bar/libraries/stuff.jar or
/usr/local/lib/myStuff.jar, chances are each of those paths only have
meaning on a specific platform anyway.

Most often,  in order to maintain the most portability, you want to use
relative paths to the build.xml file.  Absolute paths are usually used to
include common or 3rd party libraries that usually exist in different
locations per system (even different systems of the same platform, or same
platform family (i.e. Linux vs. Solaris)).  An exception might be if you
use a shared disk that's mounted by both a *nix system and a Windoze
system, but even in that case, you probably won't mount a share point to
something named c:/x/y/z on *nix, and you can't mount something like
/foo/bar on Win.

In the end, if you use absolute paths, you're probably putting a superset
of all the paths from all the platforms you're building on, and hoping the
ones that don't make sense are ignored.


Conor MacNeill wrote:
> 
> Phil,
> 
> This little area of ant causes many problems :-) I would like to explore the
> issues a little further.
> 
> >
> > Apache and Tomcat recognize and handle c:/path/path/file
> > correctly.  So does
> > Perl, most editors, most zip tools, all the java.io.* classes and all the
> > GNU utilities.  Principle of least astonishment.  Converting c:/path to
> > c;\path is a bug.  Code should be robust enough to handle it.
> 
> Fair point. However I would find the fact that all single letter paths are
> impossible under Unix somewhat astonishing ! The fact that they disappear
> quietly would be more so.
> 
> > I would think requiring paths to be written one way for Win32 and another
> > for Unix defeats the purpose of Project.translatePath().
> 
> Just to be clear, we are only talking about absolute paths, not relative
> paths. Absolute paths have to be different anyway.
> 
> > The
> > goal should be
> > that a build.xml file should be able to be lifted from one environment and
> > used in another with as little difficulty as possible.
> 
> A build file with absolute paths must be changed anyway. Can a build file
> with an absolute path ever be used without change on another platform? Your
> change could make these things harder to find since the absolute paths of
> Win32 would be accepted without any problems. The present solution isn't
> perfect detecting one platform's absolute paths being used on another
> platform. I would rather see such cases flagged as errors than just quietly
> accepting them and using some other inappropriate path.
> 
> Cheers
> Conor

-- 
Eugene Bekker
Chief Architect
PowerVision Corporation
http://www.powervision.com
tel://410/312.7243 cel://443/838.6330