ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Tulley" <JTUL...@novell.com>
Subject NetWare To-Do's (was Re: Ant 1.5 To-Do list)
Date Tue, 26 Feb 2002 21:52:23 GMT
Steve,
Ok, so here is what WinCVS reports after updating everything to the
latest version:

1)  /build.xml  - minor changes, simply adding in an include of
antRun.pl, as well as some cleanup.  Note that in the attached lines of
the diff, instead we could replace the two lines for antRun.pl and
runant.pl with *.pl

There might be some other places in the build.xml that I have missed
where antRun.pl needs to be dealt with to get it into the correct place
and "cleaned up" (<fixcrlf />??)


2) org.apache.tools.ant.PathTokenizer  - fairly major changes that I
agonized over how to make, getting input from the group.  I think in the
end I got something created that works well on all platforms and
maintains backwards compatibility.  But, that largely depends on
people's opinions of how platform independent that code SHOULD be.  I
made sure that the functionality on other platforms did not change, and
on NetWare, I assumed that file paths with the colon character were
multi-character volume names, not UNIX style path delimiters.  I
attached this submission, revised to be against the latest version of
the code.  Related to this was:


3) org.apache.tools.ant.types.PathTest  - I refactored the tests,
separating out each of the platform types so that it is easy to tell
what platform's style paths your OS is not handling.  I increased the
number and types of test cases, and added in a set of NetWare tests. 
(before there was a if (isUnixStyle) {}else{}, now there is a else if
(isNetWare).  I've attached that diff as well.   Reading and
understanding this test is probably key to understanding how
PathTokenizer currently is designed to work in a "cross-platform" way,
and that was what made the solution to the PathTokenizer NetWare support
clear in the end.  


4) org.apache.tools.ant.util.FileUtils  - There were assumptions that
any drive name that came in as part of a path would only be one
character in size, and that was how FileUtils decided that the drive
name needed to be specially dealt with.  NetWare has multiple-character
drive or volume names, so the code had to be reworked to accept drive
names of any size.  This was in resolveFile and normalize.  Looking at
the code now, the only time that backwards compatibility might be broken
is if the user passed in an invalid drive name on Windows (cd:\temp
instead of c:\temp")  On Windows, this would have generated a "cd:\temp
is not an absolute path" message before but now it would pass, since
that path could be valid on NetWare.  So, this could be changed in a
similar manner to PathTokenizer - to actually do a check if the OS we
are RUNNING on is NetWare, and only in that case allow
multiple-character drive names.


5) org.apache.tools.ant.util.FileUtilsTest  - I added in some test
cases for multiple-character volume/drive name support.  If we change
FileUtils to have an if Os.isFamily("netware") (or whatever it is), then
this test can change also to have the same check and OS dependent
behavior.


6) bin\runant.pl - I added some fixes in that are necessary on NetWare
because of a limit on the size of the command line.  Basically on
NetWare I do not expand the system classpath, but rather let that be
deferred to java itself.   No biggie, and should only effect NetWare
(via an OS detection "$^O" in Perl)

Absolute files will never be handled perfectly in a platform
independent way, since they are by nature platform dependent.  Both of
the major changes here deal with that fact, and PathTokenizer at least
only tries to make sure that the platform-specific drive names are
handled correctly.  The actual problem that I was running into had to do
with a build file that ONLY have relative paths, but eventually
something somewhere resolved "." to "sys:\jakarta-ant\dist\bin" (or
similar), and then sent that into PathTokenizer, which did not recognize
sys: as a drive name, but rather thought the colon was a UNIX path
delimiter.  Everything blew up at that point.

Sorry for the long email, but it is good to get the ball rolling
again.
Thanks,


Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

>>> steve_l@iseran.com 2/26/02 12:52:20 PM >>>

----- Original Message -----
From: "Jeff Tulley" <JTULLEY@novell.com>
To: <jakarta-ant@ehatchersolutions.com>; <ant-dev@jakarta.apache.org>
Sent: Tuesday, February 26, 2002 11:16
Subject: Re: Ant 1.5 To-Do list


> Can I get Novell NetWare support on your list?  I'll do all of the
work,
> of making sure that all my submissions work in a
backwards-compatible
> way, that the whole of the testsuite still runs on other platforms,
> etc.
>
> I've submitted a whole chunk of things, but I think only the
FileUtils
> (maybe more, I'm not sure) patch did not get accepted and committed.

can you list what is not in there; and lets see what obstacles there
are to
adding the remaining stuff

> I have just a little breathing room here at work to get this
finished
> up, and we would really like to see a release go out that works with
> NetWare.
>
> I probably ought to add some documentation also of some sort as to
> exactly what should work on NetWare.  I think there are some
problems
> still under JVM 1.1.7B due to JVM bugs, that are not going to get
fixed
> unfortunately.  JVM 1.2.2 had a few problems that might be fixable
yet,
> and JVM 1.3 seemed to work fine.  This probably ought to be spelled
out
> somewhere and fixed where possible.
>

Actually, a per-platform notes page may make sense for not just
netware, but
windows ("2s time granularity on NTFS; ...etc", Mac, Unix versions...

--
To unsubscribe, e-mail:  
<mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message