Bug 54044 - Ant log does not use system newline character
Summary: Ant log does not use system newline character
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1.2   Edit
Hardware: PC Windows All
: P4 minor (vote)
Target Milestone: 3.0 M8   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-08 11:45 EST by C. Lamont Gilbert CLA
Modified: 2004-03-25 10:40 EST (History)
2 users (show)

See Also:


Attachments
Unmolested zip of log (2.21 KB, application/octet-stream)
2004-03-09 13:26 EST, C. Lamont Gilbert CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description C. Lamont Gilbert CLA 2004-03-08 11:45:11 EST
The Ant log file uses the Linux carriage return as opposed to the system
carriage return character.

see https://bugs.eclipse.org/bugs/show_bug.cgi?id=54042 for my ant attachment
that has the Linux style carriage returns.
Comment 1 Darin Swanson CLA 2004-03-08 22:36:47 EST
Thanks for the bug report but this is not the Ant log file but rather the 
compiler log file generated by using the javac task and the jdtCompilerAdapter 
via the Export operation.

I am not sure how you could have gotten the wrong carriage returns...moving to 
JDT Core for comment.
Comment 2 Darin Swanson CLA 2004-03-08 22:37:25 EST
Wassim, have you seen anything like this? 
Not sure where this bug should live.
Comment 3 Wassim Melhem CLA 2004-03-08 22:52:32 EST
Logically, it belongs in JDT/Core because the log files are generated during 
the javac task, as Darins points out.

I'm not sure how these files are written to, but, if each line is terminated 
with System.getProperty("line.separator"), then we would get a platform-
specific carriage return.
Comment 4 Olivier Thomann CLA 2004-03-08 23:05:40 EST
All lines written in the log use the println(...) methods of the PrintWriter
class. We never explicitely use the line delimiter.
I will investigate further.
Comment 5 Wassim Melhem CLA 2004-03-09 02:26:14 EST
Olivier, PrintWriter.println() is sufficient.  
It sends values to the output stream followed by an end of line character.  
The end of line sequence used is the default for the system as determined by 
System.getProperty("line.separator").  For Windows systems,the end of line 
character is \r\n, for Unix systems, \n, and for Mac systems, \r.
Comment 6 Olivier Thomann CLA 2004-03-09 08:47:27 EST
That was my understanding. This is why I am surprised this is an issue.
I tried on Windows to generate a log file using the batch compiler and I got
Windows line delimiter in it. No problem. It works as expected.
Could you please attach in a zip file a log file generated on Windows that
contains Linux line delimiter?
Maybe your attachment has been converted by Bugzilla.
Comment 7 C. Lamont Gilbert CLA 2004-03-09 13:18:19 EST
The ant file was generated on Windows 2000 using JDK 1.4.1_07.
I right clicked my fragment.xml file and selected Create Ant Build file.
Then I right clicked the build.xml ant file and selected run ant...
I selected "build jars" and "gather logs."
I then received the compile failed error message as detailed in my other bug report.
The I opened the log file.

It appears that the log is copying text from the source file.  Just before the
copied portion there is a funny char, and just after the copied portion there is
one.  I use the term "one" loosely because I believe there are a few chars there
I do not see.

here is one example

----------
6. ERROR in
C:\eclipse2.1.2\workspace\WAD_DS_AccessDB\src\com\rigidsoftware\WAD\datasources\access\DBArchitecture.java
(at line 150)
	assert nameSuggestion != null : "System name must not be null.";
	                      ^^
Syntax error on token "!=", ";" expected
----------

Just before the spaces in front of the keyword assert.  Also just after the
semicolon

 
Comment 8 C. Lamont Gilbert CLA 2004-03-09 13:24:58 EST
I submit to you gentlemen, that the errors listed here are not the work of
javac.  Clearly javac understands the keyword 'assert.'  Furthermore, the class
files are generated without issue.

Therefore, the errors are the result of some other parsing of the class file.  A
parsing done by an entity that does not comprehend the keyword 'assert.'
Comment 9 C. Lamont Gilbert CLA 2004-03-09 13:26:25 EST
Created attachment 8437 [details]
Unmolested zip of log

zipped to preserve the line characters that bugzilla may be removing.
Comment 10 C. Lamont Gilbert CLA 2004-03-09 13:29:13 EST
Version is 2.1.2
Comment 11 C. Lamont Gilbert CLA 2004-03-19 09:26:03 EST
Has anyone verified this behavior?
I dropped the priority a notch as its just an annoyance.  I can use wordpad if I
really want to see it correctly.
Comment 12 Olivier Thomann CLA 2004-03-19 10:05:15 EST
I found the problem. I have a fix, but we need to update some tests first.
I'll see if I can do it today for next integration build.
It will be fixed in 3.0 only.
Comment 13 C. Lamont Gilbert CLA 2004-03-19 10:55:32 EST
great!
Comment 14 Olivier Thomann CLA 2004-03-19 11:12:45 EST
Fixed and released in HEAD.
All tests have been updated and passed.
Comment 15 Frederic Fusier CLA 2004-03-25 10:40:13 EST
Verified for 3.0 using build I200403250010.