> From: Michael Smith [mailto:[EMAIL PROTECTED]
> Actually, since you're talking about the Windows world, you
> can have UNC
> path names. The //c/foo/bar would conflict with a UNC path
> referring to a
> file 'bar' in the share 'foo' on computer 'c'.
You're so right...
> So far, here's what I think we can all agree on:
>
> - A developer on a windows platform prefers to use ; and \
> as the path
> and directory separators and desires the ability to use UNC names
> and drive letters followed by colons. A unix platform developer
> may prefer to use : and / (and doesn't care about UNC
> names and drive
> letters). Mac developers would prefer to use whatever
> separators are
> used on the mac platform.
>
> - The build file should be portable to other platforms, but in some
> cases it doesn't need to be.
>
> - It would be nice to support absolute paths, even for a
> build that must
> be made on multiple platforms
Agreed, although I think that support for absolute paths in a
multi-platform environment is a nice to have feature, but not at
all costs (both internal and external complexity). As you'll see
below, the build-file will become a lot more complex.
> To allow developers to use the separators that they are
> accustomed to on
> their platform, Ant would add two optional attributes to the
> project element
> in the XML file -- one specifying the path separator and one
> specifying the
> directory separator. Then, all path and dir separators that
> appear in the
> build file are interpreted based on the ones specified as
> attributes to the
> project element. If an attribute is omitted, the default for
> the local
> platform is used.
[snip]
I think this is the best idea until now on the path/dir separator
issue. So +1 for me.
> So far, I have assumed that the directory and path separators
> are consistent
> throughout the entire build file. While in most cases this
> will be true, it
> would be nice to support different separators within the same
> file. Why you
> might ask? For absolute paths. A build file may rely on
> absolute paths to
> build properly, and the absolute paths on windows and unix
> filesystems are
> specified differently.
>
> To solve this problem, I am relying on the usage of the path
> definition
> stuff proposed by Thomas Haas. In the "element" and "path"
> elements that
> are used to define a bath, a "pathseparator" and
> "dirseparator" attribute
> are optionally added. (note: the pathseparator is meaningless in the
> "element" element, as it specified only one path element).
> The attributes
> specified on the path element would override any specified at
> the project
> level.
>
> For example, consider the following build file created for
> building on a
> unix platform:
>
> <project>
> <!-- [snip] -->
> <somepath>
> <element location="../classes" />
> <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
> </somepath>
> <!-- [snip] -->
> </project>
>
> You could make this "portable" to run under Windows by
> changing it to the
> following:
>
> <project dirseparator="/" pathseparator=":">
> <!-- [snip] -->
> <somepath>
> <element location="../classes" />
> <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
> </somepath>
> <!-- [snip] -->
> </project>
>
> However, while this build file is portable, the build itself
> isn't portable
> because of the absolute paths are not going to be found on a windows
> platform. Using the path level separators, you would add the
> following to
> get the build to work on a Windows platform:
>
> <project dirseparator="/" pathseparator=":">
> <!-- [snip] -->
> <somepath>
> <element location="../classes" />
> <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
> <path definition="D:\libs;D:\libs\foo.jar"
> dirseparator="\" pathseparator=";" />
> </somepath>
> <!-- [snip] -->
> </project>
>
> Now, the absolute paths will be found on both windows and
> unix platforms
> with only one drawback -- there will be extraneous path
> information added.
> When on a Unix platform, the paths D:/libs and
> D:/libs/foo.jar will be added
> (they most likely do not exist), and on the windows platform,
> the paths
> \usr\local\classes and \usr\local\classes\foo.jar will be
> added (which also
> are unlikely to exist).
>
> To remove this potential problem, another attribute can be
> added to the
> "path" and "element" elements that specify which platform
> they should be
> added on (very similar to the "os" attribute in the exec
> taskdef). This
> portable build file would then become:
>
> <project dirseparator="/" pathseparator=":">
> <!-- [snip] -->
> <somepath>
> <element location="../classes" />
> <path definition="/usr/local/classes:/usr/local/classes/foo.jar"
> os="unix"/>
> <path definition="D:\libs;D:\libs\foo.jar"
> os="win" dirseparator="\" pathseparator=";" />
> </somepath>
> <!-- [snip] -->
> </project>
>
> Then, the path that is built will be
> On unix:
> ../classes:/usr/local/classes:/usr/local/classes/foo.jar
>
> On windows:
> ..\classes;D:\libs;D:\libs\foo.jar
>
>
> We now have a truely portable build file that will work on
> unix and windows
> and includes absolute paths. To get the build working on a
> mac, you would
> probably need to add path elements to point to foo.jar --
> although if you
> had just relied on relative paths, your life would have been
> easier... :)
It's a good idea, but doesn't it make the build-file too complex?
(Not to mention Ant itself). How is the OS name determined? "unix"
is not a OS name, but a collection of different OSs.
Let's recap:
For the user on a single platform:
- Just use the path/dir separators of the platform in the paths
in the build-file.
For the user on multiple platforms without absolute paths:
- Specify the separators in the project element
- Use these path/dir separators in your paths in the build-file.
For the user on multiple platforms with absolute paths:
- Specify the separators in the project element
- Use these path/dir separators in your paths in the build-file.
- For each absolute path, use the construct where you can set
the path based on the platform.
I assume here that the simple path declarations like
<copydir src="build" dest="../lib/dist"/>
are still possible (thus without using the path construct).
So for the most complex situation we would get (assuming the OS name
issue has been resolved):
<copydir>
<src>
<path definition="c:\foo\bar"
os="win" dirseparator="\" pathseparator=";"/>
<path definition="/usr/local/foo/bar"
os="unix" dirseparator="/" pathseparator=":"/>
</src>
<dest>
<path definition="d:\xyz"
os="win" dirseparator="\" pathseparator=";"/>
<path definition="/home/xyz"
os="unix" dirseparator="/" pathseparator=":"/>
</dest>
</copydir>
Is this all correct?
If so, I think it is a good proposal, but we should come up
with a way to that prevent tasks from being bother by complex
path constructs. How about having a "Path" type which can be
processed by the reflector in the Ant core? Then the tasks
just need the setSomePath/addSomePath methods, and Ant itself
takes care of the rest.
Cheers,
Arnout
