ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Haas <tho...@haas-wyss.ch>
Subject Re: Platform independent classpath in build.xml?
Date Mon, 05 Jun 2000 18:47:57 GMT


Conor MacNeill wrote:
[deleted]

> Actually I once proposed a patch for multiple source dirs using commas as a
> separator. I can paraphrase the reactions as
> 1. comma is a valid filename character on some platforms (RCS files)
> 2. all delimited strings are bad and we should use XML element structuring
> 3. It should have been ':'
>
> In particular, Thomas' classpath structuring falls into the second camp. I
> think that is useful but I also find delimited strings concise and natural.
> The full XML expression can be a little verbose.

[deleted]

> For example, say we are using JUnit to run tests. We define an environment
> variable with the JUnit classpath. It is used to run JUnit, so must be
> expressed in the native platform conventions. On Unix it will be a :/ style
> path and on NT a ;\ style path. Now we also want to use ant to build the
> test classes. We pass the JUnit classpath as an ant property define. IN the
> build file, we append some extra directories to the given classpath. Since
> we have only one, cross-platform, build file we choose to use :/ notation.
> When running under NT the resulting classpath has both :/ and ;\ elements.
> The current delimiter choice allows such constructs to work. Its not
> essential, but it is a nice to have.
>
> Thoughts?
>
> Conor

YES, that's why the Path object can not only be used with nested XML definitions
(the pure way) but also with predefined pathes set in a property (as your
example explains):

<classpath definition="${some.property}:/some/path/classes:/other/file.jar">
    ...
</classpath>

The parameter definition uses ':' and ';' to split the path definition into
single elements. And I think it IS essential, because sometimes youz have no
other choice but passing a complete path to ant.

Nice, we seem to agree; now it is maybe time to cleanup the mess within the Path
object. Stephan suggested to get rid of the inner class PathElement. I will not
have time until tomorrow evening, so if someone is up to it and has a patch
ready, please send it. The function parseing pathes could also be improved...
anyone up for that?

- tom




Mime
View raw message