RE: Platform independent classpath in build.xml?

[Brill Pappin <jo...@jmonkey.com>]

It would be very easy to just use the standard Ant separator for entries
(namely a ",") and have ant parse it into the OS dependant separator when
required... not problem, instant solution.

In fact, when I first tried to use it, that's exactly what I assumed would
happen... needless to say I was disappointed to find that I had to use a
native separator :(

- Brill Pappin

> -----Original Message-----
> From: root@relativity.yi.org [mailto:root@relativity.yi.org]On Behalf Of
> burtonator
> Sent: May 30, 2000 5:38 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Platform independend classpath in build.xml?
>
>
> What would be cool is a way to set the classpath in XML:
>
> <classpath inherit="true">
>     <entry>${LIBROOT}appframe.jar</entry>
> </classpath>
>
> And this would build the classpath as:
>
> $CLASSPATH;./lib/appframe.jar
>
> oooohhh...
>
> Ken Wood wrote:
> >
> > path.separator is a pre-defined property that has
> > ";" or ":" depending on what OS you're running.
> >
> > Here is what I did:
> >
> >  <property name="S" value="${path.separator}" />
> >  <property name="classpath"
> >
> value="${JCORELIB}${S}${classes}${S}${LIBROOT}/appframe.jar${S}${L
IBROOT}/font.jar"
> > />
> >
> > I used "S" becuase I didn't want path.separator over and over and
> > over...
> >
> > Lars Martin wrote:
> > >
> > > Hi all,
> > >
> > > how do I set a platform independend classpath in build.xml?
> > >
> > > Something like
> > >
> > >   <property name="classpath" value="${build.dir};${jar.dir}/..."/>
> > >
> > >   <javac srcdir="${src.dir}"
> > >        destdir="${build.dir}"
> > >        classpath="${classpath}"/>
> > >
> > > works under Windows but not under Unix. Changing ";" to ":"
> in the classpath
> > > property works under Unix but not under Windows? What did I
> wrong? Did i miss
> > > something?
> > >
> > > Lars
>
> --
> Kevin A Burton (burton@apache.org)
> http://relativity.yi.org
> Message to SUN:  "Please Open Source Java!"
> To fight and conquer in all your battles is not supreme excellence;
> supreme
> excellence consists in breaking the enemy's resistance without fighting.
>     - Sun Tzu, 300 B.C.

Re: Platform independent classpath in build.xml?

[Thomas Haas <th...@softwired-inc.com>]

----- Original Message -----
From: Brill Pappin <jo...@jmonkey.com>
>
> That's exactly my point... if you standardize the path separator, then the
> build file become platform independent. As it is now, you must use a
> separator from unix or windows... just because they are interchangeable
does
> not make them platform independent. The fact that unix and windows
> separators are interchangeable at all, is really a convenience for those
who
> are used to using a particular separator, but its not to someone who is
> familiar with an entirely different separator.
>
> > I suggest you have a read of the core.html document in the spec
directory.
> > It discusses some of these issues.
>
> Right... ok... so basically you say that ":" is the ant path separator...
> this is what I want to hear... however my point still stands that it might
> not be obvious to someone who has never seen a unix style path
separator...
> like myself (who does use unix btw) they are first going to try and use a
> comma, because most other lists in Ant use them. Its a natural assumption.
----

Lists should be defined using nested XML structures:

<classpath>
    <element location="a/path/according/to/file/spec"/>
    <element location="another/path/according/to/file/spec"/>
    <element location="on/more/path/according/to/file/spec"/>
</classpath>

... and add a way to set a path predefined in a property.
The predefined path should be parsed according to the local conventions and
some Ant standard. Using  /, \, ;, : as the standard separators is not bad,
as this will be natural for most ant users.

Note: A general path abstraction can also be used to modify the PATH
environment variable. This can be used to spawn external processes.

I will improve the existing classpath stuff a little bit and send a patch to
this list and ask for comments. Then I hope we can finally end the
discussion about files and pathes.

- tom

Re: Platform independent classpath in build.xml?

[Thomas Haas <th...@haas-wyss.ch>]

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

RE: Platform independent classpath in build.xml?

[Brill Pappin <jo...@jmonkey.com>]

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@m64.com]
> Sent: June 5, 2000 9:58 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Platform independent classpath in build.xml?
[...]
> > Right... ok... so basically you say that ":" is the ant path
> separator...
> > this is what I want to hear... however my point still stands
> that it might
> > not be obvious to someone who has never seen a unix style path
> > separator...
> > like myself (who does use unix btw) they are first going to try
> and use a
> > comma, because most other lists in Ant use them. Its a natural
> assumption.
> >
>
> Fair point, but it could be addressed with appropriate documentation.
>
> 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 ':'

Yes, I see your point... a comma might cause a problem, and you can't
*maybe* parse the comma if a comma would not cause a problem, because then
its not cross platform.

> 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.

I'd agree... an XML structure might be nice, but I like the simplicity of a
single string.

> Thoughts?

I don't like it, but I guess its the best solution for the moment... the
fact is that you can't know what chars will be used in a path, for every
system... (in windows its possible to create file names with illegal chars
in them). As far as I can see it would be best to use one char across the
board that is rarely seen in a file name, and allow it to be escaped in the
odd case it must be used (the only place you ever have the problem is in a
path list).

- Brill Pappin

RE: Platform independent classpath in build.xml?

[Conor MacNeill <co...@m64.com>]

>
> Sure... that would be a good feature, but why wouldn't you have an Ant way
> to represent the classpath?

We do. It uses ':' or ':' as the path separator and '/' or '\' as the file
separator.

>
> That's exactly my point... if you standardize the path separator, then the
> build file become platform independent. As it is now, you must use a
> separator from unix or windows... just because they are
> interchangeable does
> not make them platform independent. The fact that unix and windows
> separators are interchangeable at all, is really a convenience
> for those who
> are used to using a particular separator, but its not to someone who is
> familiar with an entirely different separator.

We have standardised the path separator as being either ':' or ';'. It is
platform independent because the translatePath method of Project will
replace either of these characters with File.pathSeparator, which is the
path separator of the native platform. The fact that the choice matches the
separators on some common platforms, while not unintentional, does not make
that choice platform dependent.

> Right... ok... so basically you say that ":" is the ant path separator...
> this is what I want to hear... however my point still stands that it might
> not be obvious to someone who has never seen a unix style path
> separator...
> like myself (who does use unix btw) they are first going to try and use a
> comma, because most other lists in Ant use them. Its a natural assumption.
>

Fair point, but it could be addressed with appropriate documentation.

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.

The second advantage of delimited strings stems from the fact that they can
be passed in from the external environment as ant property definitions. It
is here that the choice of delimiters to match those of Unix and Windows is
useful. On those platforms, classpaths defined in the native format can then
be passed directly into ant and will work as expected.

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

RE: Platform independent classpath in build.xml?

[Brill Pappin <jo...@jmonkey.com>]

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> Sent: May 31, 2000 8:34 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Platform independent classpath in build.xml?
>
[...]
> Previously my position was that I had wanted ant to be useable by people
> using their native platform conventions. If a person has to provide a
> classpath and they are used to providing it in a particular way, I wanted
> ant to accept that. The resulting build files would still have been cross
> platform, provided no absolute paths had been used. My view was based on
> Unix and Windows style platforms and I guess that view may preclude other
> platforms.

Sure... that would be a good feature, but why wouldn't you have an Ant way
to represent the classpath?
>
> > There is also no reason that the system classpath can't work in
> > conjunction
> > with an "ant classpath"... once the ant classpath is converted
> to a native
> > path at runtime, the system classpath could be appended if desired.
> >
>
> Not sure what you are getting at here.

Ahh... what I mean is that Ant could use the systems classpath that its
running in as well as its own... append it is you like. A little out of
context I know :)

> >
> > Looks like it would work, but you have hard coded the path
[...]
> > As you can see, at no point do I use a hard-coded path separator... and
> > because of that, this method should work on *any* java compliant OS,
> > regardless of what unique path separators it uses...
>
> Your code is platform independent but it makes all build files platform
> dependent. A build file which works on one platform will not work
> on another
> with a different separator. One of the major goals of ant is to
> allow build
> files to be platform independent.

That's exactly my point... if you standardize the path separator, then the
build file become platform independent. As it is now, you must use a
separator from unix or windows... just because they are interchangeable does
not make them platform independent. The fact that unix and windows
separators are interchangeable at all, is really a convenience for those who
are used to using a particular separator, but its not to someone who is
familiar with an entirely different separator.

> I suggest you have a read of the core.html document in the spec directory.
> It discusses some of these issues.

Right... ok... so basically you say that ":" is the ant path separator...
this is what I want to hear... however my point still stands that it might
not be obvious to someone who has never seen a unix style path separator...
like myself (who does use unix btw) they are first going to try and use a
comma, because most other lists in Ant use them. Its a natural assumption.

- Brill Pappin

RE: Platform independent classpath in build.xml?

[Conor MacNeill <co...@cortexebusiness.com.au>]

Brill,

> > I don't think "," is the standard ant separator. Where does it say this?
>
> It doesn't say it anywhere, but its all over Ant... call it the "unwritten
> rule"...
>

Easily broken then ... :-). In fact the current spec proposal (see File
Naming Conventions) states that in the build file the path separator is ':'
and the directory separator is '/'. The ';' and '\' characters are
alternatives.

> > Its actually better than you realise. As it stands ant will
> accept a path
> > specification with either Windows or Unix standard path separators and
> > translate to the native platform's representation. This makes ant very
> > accepting. In general I try to stick to the Unix style separators in my
> > build files even though I work mostly on NT.
>
> The trouble with it is that we assume that we're going to get a unix or a
> windows path separator... what happenes on another OS, such as JOS
> (www.jos.org)... does anyone know what will happen on an Amega? (not that
> amega is likely to ever implement a recent JDK, but the concept is sound).
> My point is, that a particular token separator is used everywhere in ant,
> except in a classpath...
>

I don't think we can get universal agreement on a path separators over all
platforms. The current behaviour accepts Windows and Unix style separators
and tries and be "accommodating". For interchange of build files between
those two families of platforms, that is pretty cool. Nevertheless, I would
be happy to fix the separators within build files to be ':' and '/'. The
build files would be platform independent and it would be up to the ant core
to cater for the platform differences. I would still want DOS style absolute
paths to be supported when running on systems which support such paths
(C:/blah).

Previously my position was that I had wanted ant to be useable by people
using their native platform conventions. If a person has to provide a
classpath and they are used to providing it in a particular way, I wanted
ant to accept that. The resulting build files would still have been cross
platform, provided no absolute paths had been used. My view was based on
Unix and Windows style platforms and I guess that view may preclude other
platforms.


> There is also no reason that the system classpath can't work in
> conjunction
> with an "ant classpath"... once the ant classpath is converted to a native
> path at runtime, the system classpath could be appended if desired.
>

Not sure what you are getting at here.

>
> Looks like it would work, but you have hard coded the path separator chars
> in some places... I think you can do the same thing without doing
> that... in
> fact I have done that very thing... here is a rough method that will be
> something like what I did, although in a slightly different context...
> I don't think it will compile without a little work (I didn't try
> it anyway)
> but you can see what I'm talking about.
>
> public static final File[] tokenizePaths(String working) {
> 	ArrayList filelist = new ArrayList();
> 	if (working != null) {
> 		if (working.indexOf(File.pathSeparator) > -1) {
> 			// this is a series of paths.
> 			// we need to tokenize the string.
> 			if (!working.endsWith(File.pathSeparator)) {
> 				// append a token, for the tokenizer.
> 				working = working + File.pathSeparator;
> 			}
> 			StringTokenizer tok = new
> StringTokenizer(working, File.pathSeparator);
> 			while (tok.hasMoreTokens()) {
> 				filelist.add(new File((String)
> tok.nextToken()));
> 			}
> 		} else {
> 			// this is a single path.
> 			File file = new File(working);
> 			filelist.add(file);
> 		}
> 	}
> 	return (File[]) filelist.toArray();
> }
>
> As you can see, at no point do I use a hard-coded path separator... and
> because of that, this method should work on *any* java compliant OS,
> regardless of what unique path separators it uses...

Your code is platform independent but it makes all build files platform
dependent. A build file which works on one platform will not work on another
with a different separator. One of the major goals of ant is to allow build
files to be platform independent.

I suggest you have a read of the core.html document in the spec directory.
It discusses some of these issues.

Cheers
Conor

RE: Platform independent classpath in build.xml?

[Brill Pappin <jo...@jmonkey.com>]

- Brill Pappin

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@m64.com]
> Sent: May 31, 2000 10:59 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Platform independent classpath in build.xml?
>
>
> >
> > It would be very easy to just use the standard Ant separator for entries
> > (namely a ",") and have ant parse it into the OS dependant
> separator when
> > required... not problem, instant solution.
> >
>
> I don't think "," is the standard ant separator. Where does it say this?

It doesn't say it anywhere, but its all over Ant... call it the "unwritten
rule"...

> > In fact, when I first tried to use it, that's exactly what I
> assumed would
> > happen... needless to say I was disappointed to find that I had to use a
> > native separator :(
>
> Its actually better than you realise. As it stands ant will accept a path
> specification with either Windows or Unix standard path separators and
> translate to the native platform's representation. This makes ant very
> accepting. In general I try to stick to the Unix style separators in my
> build files even though I work mostly on NT.

The trouble with it is that we assume that we're going to get a unix or a
windows path separator... what happenes on another OS, such as JOS
(www.jos.org)... does anyone know what will happen on an Amega? (not that
amega is likely to ever implement a recent JDK, but the concept is sound).
My point is, that a particular token separator is used everywhere in ant,
except in a classpath...

There is also no reason that the system classpath can't work in conjunction
with an "ant classpath"... once the ant classpath is converted to a native
path at runtime, the system classpath could be appended if desired.

> BTW, I wrote a class to tokenize paths into path components and I then
> rewrote Project.translatePath to use it. This actually addresses a problem
> raised by Phil Hanna to support absolute paths of the form
> C:/blah. It does
> this without affecting the ability for single letter Unix paths to be
> supported. The tokenizer is reusable in other places in the ant code where
> you need to iterate over the components of a path.
>
> I have attached it for comment.

Looks like it would work, but you have hard coded the path separator chars
in some places... I think you can do the same thing without doing that... in
fact I have done that very thing... here is a rough method that will be
something like what I did, although in a slightly different context...
I don't think it will compile without a little work (I didn't try it anyway)
but you can see what I'm talking about.

public static final File[] tokenizePaths(String working) {
	ArrayList filelist = new ArrayList();
	if (working != null) {
		if (working.indexOf(File.pathSeparator) > -1) {
			// this is a series of paths.
			// we need to tokenize the string.
			if (!working.endsWith(File.pathSeparator)) {
				// append a token, for the tokenizer.
				working = working + File.pathSeparator;
			}
			StringTokenizer tok = new StringTokenizer(working, File.pathSeparator);
			while (tok.hasMoreTokens()) {
				filelist.add(new File((String) tok.nextToken()));
			}
		} else {
			// this is a single path.
			File file = new File(working);
			filelist.add(file);
		}
	}
	return (File[]) filelist.toArray();
}

As you can see, at no point do I use a hard-coded path separator... and
because of that, this method should work on *any* java compliant OS,
regardless of what unique path separators it uses...

RE: Platform independent classpath in build.xml?

[Conor MacNeill <co...@m64.com>]

>
> It would be very easy to just use the standard Ant separator for entries
> (namely a ",") and have ant parse it into the OS dependant separator when
> required... not problem, instant solution.
>

I don't think "," is the standard ant separator. Where does it say this?

> In fact, when I first tried to use it, that's exactly what I assumed would
> happen... needless to say I was disappointed to find that I had to use a
> native separator :(

Its actually better than you realise. As it stands ant will accept a path
specification with either Windows or Unix standard path separators and
translate to the native platform's representation. This makes ant very
accepting. In general I try to stick to the Unix style separators in my
build files even though I work mostly on NT.

BTW, I wrote a class to tokenize paths into path components and I then
rewrote Project.translatePath to use it. This actually addresses a problem
raised by Phil Hanna to support absolute paths of the form C:/blah. It does
this without affecting the ability for single letter Unix paths to be
supported. The tokenizer is reusable in other places in the ant code where
you need to iterate over the components of a path.

I have attached it for comment.

Conor