Return-Path: <thomas.haas@softwired-inc.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 83835 invoked from network); 20 Apr 2000 12:16:27 -0000
Received: from i-gate.softwired.ch (212.40.20.70)
  by locus.apache.org with SMTP; 20 Apr 2000 12:16:27 -0000
Received: from artus.ii.softwired.ch (camelot.softwired.ch [212.40.20.71])
	by i-gate.softwired.ch (8.9.1/8.9.1) with ESMTP id OAA15585
	for <ant-dev@jakarta.apache.org>; Thu, 20 Apr 2000 14:16:22 +0200
Received: from softwired-inc.com (mordred.ii.softwired.ch [192.168.168.222])
	by artus.ii.softwired.ch (8.9.3/8.9.3) with ESMTP id OAA05056
	for <ant-dev@jakarta.apache.org>; Thu, 20 Apr 2000 14:16:21 +0200
Message-ID: <38FEF510.CC6B9847@softwired-inc.com>
Date: Thu, 20 Apr 2000 14:16:16 +0200
From: Thomas Haas <thomas.haas@softwired-inc.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Path & dir separators (was Re: Ant Principles)
References: <Pine.LNX.4.21.0004200944040.13065-100000@marni.otago.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N



Mariusz Nowostawski wrote:

> sounds all right to me as well.
> However, it is not appealing to me to type
>    dirseparator="\" pathseparator=";"    and
>    dirseparator="/" pathseparator=":"    and
>      others ....
> all over again in milions of places.
>
> _If_ the OS name issue has been resolved, the OS could have associated
> default separators and it could be more compact to use:
>
>    <src>
>      <path os="win" definition="c:\foo\bar" />
>      <path os="unix" definition="/usr/local/foo/bar" />
>    </src>
>
> Thus "os" could be really not an indication of OS, but indication of the
> family of conventions for filesystem path expressions, i.e. unix-like,
> windows-like, macos-like, vms-like, etc.  Each OS has than associated
> filesystem path expression convention, and linux-solaris, linux-i686, and
> hpux for example are all using unix-like filesystem path expression
> conventions. With some luck ;o) we would need to define only some
> mappings (say windows, mac, vms), and for "unknown" assume unix-like
> conventions.

Three different problems regarding files and pathes need to be solved:

  1. Defining files or directories static in the build file in a crossplatform
     way
  2. Defining pathes (lists of files or directories) static in the build file
     in a crossplatform way
  3. Interpreting pathes and files or directories defined in properties. This
     is different than 1 or 2, as the property may be defined on the command
     line with value defined by the local envrionment like environment
     variables or as output from other commands on that platform.

The discussion revolved around 1) and 2), which can be done in various ways as
proposed by many posters, but the real problem is in 3), as local and build
file definitions are (potentially) mixed.

True absolute pathes are probably very rarly defined. We always define a
property pointing to some base directory and using a relative file to that
base, because true absolute pathes always violate local filesystem layouts.
The base therefor is always defined as common on the current platform, whereas
the static relative part is defined in one ways.


Proposal:

   * Define pathes using nested elements (unless passed in as property).
     Elements are files (or directories) defined by the rules for files
   * Use a syntax to use whatever is specified to create a java.io.File
     object. This works on every platform for local conventions and works very
     well across Windows and Unix.
   * Define some (hairy) way to define files in a real crossplatform manner.
     This may leads to URLs as they are translation rules already exists for
     every platform.
   * Pathes need only be parsed, if they are read from properties and mostly
     specified as defined by the local platform.

<somepath>
    <path localdefinition="${class.path}"/>  <!-- defined by the local env.
and parsed accordingly -->
    <path populardefinition="${other.class.path}" <!-- like ant does today,
see above -->
    <path antdefinition="${ant.way.path}"/>  <!-- define a true crossplatfrom
syntax -->
    <element file="../foo/file.jar"/>   <!-- works with the file onject on
most platforms, maybe even all -->
    <composit>
        <base file="${foo.basedir}"/>        <!-- base directory -->
        <location file="${foo.basedir}"/>    <!-- relative file to base -->
    </composit>
    <element antdefined="(..)(foo)(file)(jar)"/> <!-- any syntax to be defined
which will work on any platform -->
    <element url="file:///foo/bar/classes"/>  <!-- file url -->
</somepath>
(all possibilities will usually not show up in the same definition as shown
here)

Explanation:

   * Use localdefinition if you intend to use something defined locally on
     every platform and use the pathseparator and fileseparator to parse this
     according to the platform's rules.
   * Use populardefinition is whta ant does today, which works well in a Unix
     and Windows mixed environment as described above.
   * Define a syntax to define pathes really crossplatform, maybe strange like
     {(foo)(file)(jar)}{(foo)(bar)(classes)}
   * The object created for the base and location elements, would be the same
     as for "element" and allow everything possible with element for base and
     location aswell.

Note:
All naming has been chosen to be explain the concepts not as a proposal for
the names itself.


Advantage:
It works well on Unix and Windows platforms. It works as expected on both
platforms. Add other pltaforms by enhancing the element and the path objects
as soon as needed.


Status:
The Path object today provides the funtionality for "path populardefinition"
and "element file". It is simple and works well at our site (Linux, Solaris,
Windows).

- tom

--
* Thomas Haas             <mailto:thomas.haas@softwired-inc.com>
* SoftWired AG                   <http://www.softwired-inc.com/>
* Technoparkstr. 1  ***  CH-8005 Zurich  ***  +41-1-4452370