You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by James Duncan Davidson <ja...@eng.sun.com> on 1999/11/25 00:48:08 UTC
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
jons@hyperreal.org wrote:
>
> jons 99/11/24 10:46:02
>
> Modified: ant/src/main/org/apache/tools/ant/taskdefs Javac.java
> Log:
> fix thanks to glenn_twiggs@bmc.com
>
> Revision Changes Path
> 1.12 +2 -1 jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs/Javac.java
>
> Index: Javac.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs/Javac.java,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -r1.11 -r1.12
> --- Javac.java 1999/11/23 21:54:47 1.11
> +++ Javac.java 1999/11/24 18:45:59 1.12
> @@ -306,7 +306,8 @@
> // add our classpath to the mix
>
> if (compileClasspath != null) {
> - StringTokenizer tok = new StringTokenizer(compileClasspath, ":",
> + StringTokenizer tok = new StringTokenizer(compileClasspath,
> + File.pathSeparator,
Actually, dont do this... I haven't yet written up how the format of the
build.xml files should be, but we need a "standard" path and file
seperator in use there that gets translated to native system path
seperator. That's the whole point of parsing here on the ":". If you run
this now on another system, you wont' get valid parsing behavior.
Please back this out.
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: cvs commit:
jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs Javac.java
Posted by jon * <jo...@clearink.com>.
on 11/24/99 3:48 PM, James Duncan Davidson <ja...@eng.sun.com>
wrote:
> Actually, dont do this... I haven't yet written up how the format of the
> build.xml files should be, but we need a "standard" path and file
> seperator in use there that gets translated to native system path
> seperator. That's the whole point of parsing here on the ":". If you run
> this now on another system, you wont' get valid parsing behavior.
>
> Please back this out.
Ah. Very good point. I will back it out ASAP.
-jon
RE: CVS question
Posted by "Preston L. Bannister" <pr...@home.com>.
From: Rob Nikander [mailto:rob@mindspring.com]
> I already have the source because I downloaded jakarta-tomcat and jakarta-tools from the web.
> Does that mean I really just want to do a "cvs update."
This could have worked... but it looks like whomever is creating the TAR file has a different path to CVS than you and I.
Rob:
Empty out the directory ("rm -rf *") before running the CVS checkout. After the initial checkout you will be able to just run CVS
update.
To whomever is creating the TAR file:
If you checkout Tomcat from CVS using the public path, then what Rob tried will work. Should cut the load on the CVS server (which
seems a tad slow for some reason) somewhat.
CVS question
Posted by Rob Nikander <ni...@mindspring.com>.
I'm new to open source projects. I'd like to be able to update my tomcat source as it changes, so that I can keep up with changes
and hopefully someday contribute. I'm not too familiar with CVS, but on the jakarta webpage it says to type:
cvs -d :pserver:anoncvs@dev.apache.org:/home/cvspublic login
password: anoncvs
cvs -d :pserver:anoncvs@dev.apache.org:/home/cvspublic checkout [module-name]
I already have the source because I downloaded jakarta-tomcat and jakarta-tools from the web. Does that mean I really just want to
do a "cvs update." Either way I get errors. The commands and error messages are below. Any help is appreciated. Thanks.
Rob
[rob@kanchenjunga jakarta]$ ls
build/ jakarta-tools/
jakarta-tomcat/ jakarta-tools_19991030222247.tar.gz
jakarta-tomcat_19991030222128.tar.gz
[rob@kanchenjunga jakarta]$ cvs -d :pserver:anoncvs@dev.apache.org:/home/cvspublic login
(Logging in to anoncvs@dev.apache.org)
CVS password:
[rob@kanchenjunga jakarta]$ cvs -d :pserver:anoncvs@dev.apache.org:/home/cvspublic update jakarta-tomcat
cvs update: warning: unrecognized response `cvs: setgroups: Operation not permitted' from cvs server
Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error:
'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE
Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error:
'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE
Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error:
'Directory' missingE protocol error: directory '/home/cvs/jakarta-tomcat' not within root '/home/cvspublic'
[rob@kanchenjunga jakarta]$ cvs -d :pserver:anoncvs@dev.apache.org:/home/cvspublic checkout jakarta-tomcat
cvs checkout: warning: unrecognized response `cvs: setgroups: Operation not permitted' from cvs server
? GenericServlet.class
? ServletException.class
? ServletOutputStream.class
? ServletRequest.class
? ServletResponse.class
? Servlet.class
? ServletConfig.class
? ServletContext.class
? ServletInputStream.class
? RequestDispatcher.class
? HttpServlet.class
? NoBodyResponse.class
? NoBodyOutputStream.class
? HttpServletResponse.class
? HttpServletRequest.class
? Cookie.class
? HttpSession.class
? HttpSessionContext.class
protocol error: directory '/home/cvs/jakarta-tomcat' not within root '/home/cvspublic'
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Roland Turner <ra...@arrakis.com.au>.
Stefano Mazzocchi wrote:
> Roland Turner wrote:
<snip>
> > void setDir(String[] values);
> > void setDir(int index, String value);
> > String getDir(int index);
> > String[] getDir();
> >
> > This way, we have all of the bases covered. The XML is clean (no
> > additional text formatting conventions), the API is clean (no use of
> > "set" to mean "add"), and bean introspection will work in the desirable
> > fashion (the multi-valued property will indeed appear as an "indexed"
> > property).
> >
> > Is this useful, or have I missed the point completely?
>
> It is, but I like addxxx() more than using arrays since they don't
> provide problems in introspections, the design is clean and the
> implementation effort doesn't change.
OK, no problem. It's not at all critical that this be exposed as a
JavaBeans property.
I am interested in your "problems in introspections" comment,
particularly in light of the above pattern being a part of the JavaBeans
spec. What problems are you referring to? Just the increase in
complexity in specifying an array type, or something else?
- Raz
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Stefano Mazzocchi <st...@apache.org>.
Roland Turner wrote:
>
> James Duncan Davidson wrote:
>
> > Stefano Mazzocchi wrote:
> <snip>
> > > so that setxxxElement methods know that they can be called multiple
> > > times.
> >
> > I could go for this pattern except that the methods for this use should
> > be addXXX, not setXXX since there are multiple possibilities here.
>
> Maybe it's a little soon for me to be jumping into the guts of design
> issues, having been lurking for just a couple of days, but here are some
> thoughts, the last of which may resolve the dilemma:
>
> - Definining our own text structuring syntax when XML already does so
> seems undesirable. Defining an element is a preferable approach in most
> cases.
>
> - Repeated calling of setXXX where the actual semantic is "add" not
> "set" also seems undesirable. addXXX() would certainly be nicer.
>
> - Nicer still might be to have this multi-valued item appear as a
> property, even through the JavaBeans design patterns. There is a clean
> approach. The JavaBeans design patterns provide for "indexed"
> properties, where the accessor methods are:
>
> void setDir(String[] values);
> void setDir(int index, String value);
> String getDir(int index);
> String[] getDir();
>
> This way, we have all of the bases covered. The XML is clean (no
> additional text formatting conventions), the API is clean (no use of
> "set" to mean "add"), and bean introspection will work in the desirable
> fashion (the multi-valued property will indeed appear as an "indexed"
> property).
>
> Is this useful, or have I missed the point completely?
It is, but I like addxxx() more than using arrays since they don't
provide problems in introspections, the design is clean and the
implementation effort doesn't change.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Roland Turner <ra...@arrakis.com.au>.
James Duncan Davidson wrote:
> Stefano Mazzocchi wrote:
<snip>
> > so that setxxxElement methods know that they can be called multiple
> > times.
>
> I could go for this pattern except that the methods for this use should
> be addXXX, not setXXX since there are multiple possibilities here.
Maybe it's a little soon for me to be jumping into the guts of design
issues, having been lurking for just a couple of days, but here are some
thoughts, the last of which may resolve the dilemma:
- Definining our own text structuring syntax when XML already does so
seems undesirable. Defining an element is a preferable approach in most
cases.
- Repeated calling of setXXX where the actual semantic is "add" not
"set" also seems undesirable. addXXX() would certainly be nicer.
- Nicer still might be to have this multi-valued item appear as a
property, even through the JavaBeans design patterns. There is a clean
approach. The JavaBeans design patterns provide for "indexed"
properties, where the accessor methods are:
void setDir(String[] values);
void setDir(int index, String value);
String getDir(int index);
String[] getDir();
This way, we have all of the bases covered. The XML is clean (no
additional text formatting conventions), the API is clean (no use of
"set" to mean "add"), and bean introspection will work in the desirable
fashion (the multi-valued property will indeed appear as an "indexed"
property).
Is this useful, or have I missed the point completely?
- Raz
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Stefano Mazzocchi <st...@apache.org>.
James Duncan Davidson wrote:
>
> Stefano Mazzocchi wrote:
> > <project>
> > <target>
> > <javac debug="true">
> > <dir>c:/java/classes</dir>
> > <dir>/usr/local/java</dir>
> > </javac>
> > </target>
> > </project>
> >
> > gets introspected into
> >
> > Project
> > +-> Target
> > +-> Javac
> > +-> setDebugAttribute("true")
> > +-> setDirElement("c:/java/classes");
> > +-> setDirElement("/usr/local/java");
> >
> > so that setxxxElement methods know that they can be called multiple
> > times.
>
> I could go for this pattern except that the methods for this use should
> be addXXX, not setXXX since there are multiple possibilities here.
Totally. You're right.
+1 for addXXX.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by James Duncan Davidson <ja...@eng.sun.com>.
Stefano Mazzocchi wrote:
> <project>
> <target>
> <javac debug="true">
> <dir>c:/java/classes</dir>
> <dir>/usr/local/java</dir>
> </javac>
> </target>
> </project>
>
> gets introspected into
>
> Project
> +-> Target
> +-> Javac
> +-> setDebugAttribute("true")
> +-> setDirElement("c:/java/classes");
> +-> setDirElement("/usr/local/java");
>
> so that setxxxElement methods know that they can be called multiple
> times.
I could go for this pattern except that the methods for this use should
be addXXX, not setXXX since there are multiple possibilities here.
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Stefano Mazzocchi <st...@apache.org>.
"Preston L. Bannister" wrote:
>
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> > The solution I'm currently mulling over is to whitespace delimit. If
> > there's path with spaces, quote it... So it would look like:
> >
> > <...list="dir1 dir2 'c:\program files\foo'".../>
> >
> > Then, anything that was a '/' or a '\' would be treated as a directory
> > seperator.
> >
> > Comments?
>
> A mild concern - The most common error is to write:
>
> <...list="dir1 dir2 c:\program files\foo".../>
>
> Explicit seperator characters (as used in English) are perhaps slightly
> better as they are a bit more visual:
>
> <...list="dir1,dir2,c:\program files\foo".../>
> <...list="dir1;dir2;c:\program files\foo".../>
>
> (Having just read the XML book :) - Isn't this where we should use elements
> rather than an attribute? You can only have one instance of an attribute.
> You can have any number of elements.
Now this is the best comment.
The element vs. attribute thread is never-ending and goes on since the
old SGML days. Almost every key player in the SGML/XML world knows this
is mostly a religious issue, but when you end up with problems like
these.
I totally agree: good DTD design practices force you to use elements
when you can have more instances of the same thing. In this case,
classpath, files, packages, whatever.
This removes all-together the need for defining a system independent
method to separate tokens, since the XML syntax does just that.
On the other hand, as I previously commented to the XML Data Binding WG
for the JCP, it gets _very_ tricky to find a way to "bean-ize" an XML
document, and kind of a pain to introspect a bean with a general XML
file.
Well, if we create a special XML schema that forces you to use just a
fixed number of layers, you can have something like
<project>
<target>
<javac debug="true">
<dir>c:/java/classes</dir>
<dir>/usr/local/java</dir>
</javac>
</target>
</project>
gets introspected into
Project
+-> Target
+-> Javac
+-> setDebugAttribute("true")
+-> setDirElement("c:/java/classes");
+-> setDirElement("/usr/local/java");
so that setxxxElement methods know that they can be called multiple
times.
How does this sound?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Stefano Mazzocchi <st...@apache.org>.
"Preston L. Bannister" wrote:
>
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> > The solution I'm currently mulling over is to whitespace delimit. If
> > there's path with spaces, quote it... So it would look like:
> >
> > <...list="dir1 dir2 'c:\program files\foo'".../>
> >
> > Then, anything that was a '/' or a '\' would be treated as a directory
> > seperator.
> >
> > Comments?
>
> A mild concern - The most common error is to write:
>
> <...list="dir1 dir2 c:\program files\foo".../>
>
> Explicit seperator characters (as used in English) are perhaps slightly
> better as they are a bit more visual:
>
> <...list="dir1,dir2,c:\program files\foo".../>
> <...list="dir1;dir2;c:\program files\foo".../>
>
> (Having just read the XML book :) - Isn't this where we should use elements
> rather than an attribute? You can only have one instance of an attribute.
> You can have any number of elements.
Now this is the best comment.
The element vs. attribute thread is never-ending and goes on since the
old SGML days. Almost every key player in the SGML/XML world knows this
is mostly a religious issue, but when you end up with problems like
these.
I totally agree: good DTD design practices force you to use elements
when you can have more instances of the same thing. In this case,
classpath, files, packages, whatever.
This removes all-together the nX-Mozilla-Status: 0009tem independent
method to separate tokens, since the XML syntax does just that.
On the other hand, as I previously commented to the XML Data Binding WG
for the JCP, it gets _very_ tricky to find a way to "bean-ize" an XML
document, and kind of a pain to introspect a bean with a general XML
file.
Well, if we create a special XML schema that forces you to use just a
fixed number of layers, you can have something like
<project>
<target>
<javac debug="true">
<dir>c:/java/classes</dir>
<dir>/usr/local/java</dir>
</javac>
</target>
</project>
gets introspected into
Project
+-> Target
+-> Javac
+-> setDebugAttribute("true")
+-> setDirElement("c:/java/classes");
+-> setDirElement("/usr/local/java");
so that setxxxElement methods know that they can be called multiple
times.
How does this sound?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able X-Mozilla-Status: 0009cing star.
<st...@apache.org> Friedrich Nietzsche
RE: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs Javac.java
Posted by "Preston L. Bannister" <pr...@home.com>.
From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> The solution I'm currently mulling over is to whitespace delimit. If
> there's path with spaces, quote it... So it would look like:
>
> <...list="dir1 dir2 'c:\program files\foo'".../>
>
> Then, anything that was a '/' or a '\' would be treated as a directory
> seperator.
>
> Comments?
A mild concern - The most common error is to write:
<...list="dir1 dir2 c:\program files\foo".../>
Explicit seperator characters (as used in English) are perhaps slightly
better as they are a bit more visual:
<...list="dir1,dir2,c:\program files\foo".../>
<...list="dir1;dir2;c:\program files\foo".../>
(Having just read the XML book :) - Isn't this where we should use elements
rather than an attribute? You can only have one instance of an attribute.
You can have any number of elements.
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by James Duncan Davidson <ja...@eng.sun.com>.
Stefano Mazzocchi wrote:
> Why don't we use nice simple commas instead? we do this in jserv and
> nobody ever complained.
The solution I'm currently mulling over is to whitespace delimit. If
there's path with spaces, quote it... So it would look like:
<...list="dir1 dir2 'c:\program files\foo'".../>
Then, anything that was a '/' or a '\' would be treated as a directory
seperator.
Comments?
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by Stefano Mazzocchi <st...@apache.org>.
"Preston L. Bannister" wrote:
>
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> >
> > jons@hyperreal.org wrote:
> [snip]
> > > RCS file: /home/cvs/jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs/Javac.java,v
> > > diff -u -r1.11 -r1.12
> > > --- Javac.java 1999/11/23 21:54:47 1.11
> > > +++ Javac.java 1999/11/24 18:45:59 1.12
> > > @@ -306,7 +306,8 @@
> > > // add our classpath to the mix
> > >
> > > if (compileClasspath != null) {
> > > - StringTokenizer tok = new StringTokenizer(compileClasspath, ":",
> > > + StringTokenizer tok = new StringTokenizer(compileClasspath,
> > > + File.pathSeparator,
> >
> > Actually, dont do this... I haven't yet written up how the format of the
> > build.xml files should be, but we need a "standard" path and file
> > seperator in use there that gets translated to native system path
> > seperator. That's the whole point of parsing here on the ":". If you run
> > this now on another system, you wont' get valid parsing behavior.
>
> You do realize that ":" is an in-path character on Win32?
I was thinking the exact same thing.
> For example:
>
> CLASSPATH=.;C:\VisualCafePDE\BIN\COMPONENTS\SYMBEANS.JAR;C:\VisualCafePDE\JAVA\LIB\CLASSES.ZIP;C:\VisualCafePDE\JAVA\LIB
>
> Which is why ";" is used on Win32.
Right.
Why don't we use nice simple commas instead? we do this in jserv and
nobody ever complained.
classpath="c:\java\code , /usr/local/bin ,
whatever#platform#comes#next"
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by James Duncan Davidson <ja...@eng.sun.com>.
"Preston L. Bannister" wrote:
> > Yes. I do. I know that it might be a shock, but irregardless of the fact
> > that I work at Sun, home of mighty Unix systems, I do most of my work on
> > a Windows laptop. I'm quite familiar with the idiocies of most operating
> > systems at this point, thank you very much.
>
> You're welcome :).
>
> Have to ask. Can't always tell from this end of the wire.
Fair enough.. :)
> I agree that everything on the same drive is good practice,
> but not always practical.
Yeah. Like I said, good design practices can't necessarily be forced by
the tool.
> I don't see any references in the sources extracted from CVS.
> The code you are talking about is off on a branch or outside Tomcat?
ProjectHelper uses the reflection apis to map <... classpath="foo"../>
to the equivalent of task.setClasspath("foo"); -- hence you'll not see
the method called explicitly, but if you set a breakpoint on it the
setClasspath method in a debugger and run it, you'll see the method
call.
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
RE: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs Javac.java
Posted by "Preston L. Bannister" <pr...@home.com>.
From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> "Preston L. Bannister" wrote:
> > You do realize that ":" is an in-path character on Win32?
> Yes. I do. I know that it might be a shock, but irregardless of the fact
> that I work at Sun, home of mighty Unix systems, I do most of my work on
> a Windows laptop. I'm quite familiar with the idiocies of most operating
> systems at this point, thank you very much.
You're welcome :).
Have to ask. Can't always tell from this end of the wire.
> The design was made based on the assumption that everything in a
> workspace is relative, or can be expressed as relative to the '/' root.
> Of course, looking at this, it's obvious that this doesn't allow
> somebody to have a project on C: and declare things on D:. Not that this
> is good practice, but a tool shouldn't mandate good style. :)
I agree that everything on the same drive is good practice,
but not always practical.
In my actual case large drive with bulky software installations (including
multiple JDK, JSDK and JWS versions) that is not backed up. I have a smaller
regularly backed up partition with my working files.
Guess what? My classpath must include drive letters... :).
> setClasspath is called by the project helper as it builds the task from
> the XML definition file and not meant to be called during the execution
> of the Task.
I don't see any references in the sources extracted from CVS.
The code you are talking about is off on a branch or outside Tomcat?
Re: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs
Javac.java
Posted by James Duncan Davidson <ja...@eng.sun.com>.
"Preston L. Bannister" wrote:
> You do realize that ":" is an in-path character on Win32?
Yes. I do. I know that it might be a shock, but irregardless of the fact
that I work at Sun, home of mighty Unix systems, I do most of my work on
a Windows laptop. I'm quite familiar with the idiocies of most operating
systems at this point, thank you very much.
The design was made based on the assumption that everything in a
workspace is relative, or can be expressed as relative to the '/' root.
Of course, looking at this, it's obvious that this doesn't allow
somebody to have a project on C: and declare things on D:. Not that this
is good practice, but a tool shouldn't mandate good style. :)
So, yes, there needs to be a bit more thought here <sigh>
> public void setClasspath(String classpath) {
> compileClasspath = Project.translatePath(classpath);
> }
> ---
> Where translatePath() maps ":" or ";" into System.getProperty("path.separator").
>
> So the original code was broken on Win32. This patch should work everywhere.
>
> If you want a standard classpath seperator ";" is a better candidate. Of course Unix filenames can contain ":" or ";" -- but that
> is rather unusual.
>
> Though setClasspath() is never called and compileClasspath is not otherwise set...
setClasspath is called by the project helper as it builds the task from
the XML definition file and not meant to be called during the execution
of the Task.
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
RE: cvs commit: jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs Javac.java
Posted by "Preston L. Bannister" <pr...@home.com>.
From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
>
> jons@hyperreal.org wrote:
[snip]
> > RCS file: /home/cvs/jakarta-tools/ant/src/main/org/apache/tools/ant/taskdefs/Javac.java,v
> > diff -u -r1.11 -r1.12
> > --- Javac.java 1999/11/23 21:54:47 1.11
> > +++ Javac.java 1999/11/24 18:45:59 1.12
> > @@ -306,7 +306,8 @@
> > // add our classpath to the mix
> >
> > if (compileClasspath != null) {
> > - StringTokenizer tok = new StringTokenizer(compileClasspath, ":",
> > + StringTokenizer tok = new StringTokenizer(compileClasspath,
> > + File.pathSeparator,
>
> Actually, dont do this... I haven't yet written up how the format of the
> build.xml files should be, but we need a "standard" path and file
> seperator in use there that gets translated to native system path
> seperator. That's the whole point of parsing here on the ":". If you run
> this now on another system, you wont' get valid parsing behavior.
You do realize that ":" is an in-path character on Win32?
For example:
CLASSPATH=.;C:\VisualCafePDE\BIN\COMPONENTS\SYMBEANS.JAR;C:\VisualCafePDE\JAVA\LIB\CLASSES.ZIP;C:\VisualCafePDE\JAVA\LIB
Which is why ";" is used on Win32.
Also looking at the code:
---
public void setClasspath(String classpath) {
compileClasspath = Project.translatePath(classpath);
}
---
Where translatePath() maps ":" or ";" into System.getProperty("path.separator").
So the original code was broken on Win32. This patch should work everywhere.
If you want a standard classpath seperator ";" is a better candidate. Of course Unix filenames can contain ":" or ";" -- but that
is rather unusual.
Though setClasspath() is never called and compileClasspath is not otherwise set...