Bug 141795 - External Tools > Ant Build: Set "Base Directory" in Japanese yields "Basedir does not exist"
Summary: External Tools > Ant Build: Set "Base Directory" in Japanese yields "Basedir ...
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Ant (show other bugs)
Version: 3.2   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.3   Edit
Assignee: Kevin Barnes CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-15 12:12 EDT by David Rostowsky CLA
Modified: 2013-06-12 06:26 EDT (History)
2 users (show)

See Also:


Attachments
The launch configuration for the repro (7.36 KB, application/octet-stream)
2006-05-15 17:18 EDT, David Rostowsky CLA
no flags Details
The simple build.xml (173 bytes, text/xml)
2006-05-15 17:19 EDT, David Rostowsky CLA
no flags Details
Screenshot of System Preferences > International (94.48 KB, image/png)
2006-06-12 16:28 EDT, David Rostowsky CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Rostowsky CLA 2006-05-15 12:12:47 EDT
Im using 3.2 RC1, but I also repro'ed it in 3.2RC4.

In the External Tools > Ant Build UI, (Main tab) I set the "Base Directory" to have a mix of English and Japanese. 

For example,
/English1/English2/<JapaneseCharacters>/English3/

When I run the ant script, I get the following error in the console window.

BUILD FAILED 
myscript.xml:16: Basedir /English1/English2/???????t}Ce??CX???/English3 does not exist

If I replace the Japanese with its English translation, it works great (in our product, thats not an option though).

Everything looks good in the Ant Launch Configuration Main tab UI. That is, the Japanese characters display correctly. Even single stepping shows the correct Japanese characters in the debugger.

Further info. Im launching in a separate JRE (1.5.0 Rel 4 on Mac). 

I have also set up the Mac to be completely in Japanese.

I suspect this will duplicate on all platforms, and probably with just all Japanese as well.
Comment 1 David Rostowsky CLA 2006-05-15 12:45:33 EDT
I was doing this all initially programmatically using the AntLaunchDelegate, so I resorted to using the UI to remove my code from the equation. Ultimately, Ill need to do this programmatically whatever the solution.
Comment 2 Kevin Barnes CLA 2006-05-15 14:17:21 EDT

*** This bug has been marked as a duplicate of 32206 ***
Comment 3 Kevin Barnes CLA 2006-05-15 14:33:17 EDT
Reopening.
Although I didn't expect it to work, this is actually working fine for me with a hello world style build file that I created inside the project attached to bug 32206.
Also, this problem looks like it's related to the resolution of your basedir which would indicate that your process has been created successfully (different from bug 32206)
Could you please attach a project containing a build file that demonstrates the problem?
Comment 4 David Rostowsky CLA 2006-05-15 17:18:44 EDT
Created attachment 41519 [details]
The launch configuration for the repro

Here's the launch I used.
Comment 5 David Rostowsky CLA 2006-05-15 17:19:05 EDT
Created attachment 41520 [details]
The simple build.xml
Comment 6 David Rostowsky CLA 2006-05-15 17:21:24 EDT
Side issue, but related...

I noticed in some of my testing that the same Japanese characters were not happy in the "Main" tab "BuildFile:" field. I didnt get any error dialogs, but the Ant script never ran. 
Comment 7 Kevin Barnes CLA 2006-06-08 13:26:45 EDT
What build are you using to reproduce this? So far I haven't been able to make my build files fail. 

my build.xml:
<project default="echoTarget">
	<target name="echoTarget">
		<echo>basedir: ${basedir}</echo>
		<echo>Hello World</echo>
	</target>
</project>

output:
Buildfile: /Users/kevinbarnes/Eclipse/buildfiles/????????????/bin/build.xml
echoTarget:
     [echo] basedir: /Users/kevinbarnes/Eclipse/buildfiles/????????????/bin
     [echo] Hello World
BUILD SUCCESSFUL
Total time: 454 milliseconds
Comment 8 David Rostowsky CLA 2006-06-08 14:31:25 EDT
we were using 3.2 RC1, but I believe I reproed it with RC4 as well. 

Youre trying this on a Mac, or a PC?
Comment 9 Kevin Barnes CLA 2006-06-08 14:35:05 EDT
I'm using a Mac and last night's build N20060608-0010.
Comment 10 David Rostowsky CLA 2006-06-08 14:40:19 EDT
Ok, thx. Ill try that build out.
Comment 11 David Rostowsky CLA 2006-06-12 16:28:18 EDT
Created attachment 44192 [details]
Screenshot of System Preferences > International

Screenshot of System Preferences > International
Comment 12 David Rostowsky CLA 2006-06-12 16:32:14 EDT
I was able to duplicate your success only if System Preferences > International shows English as the primary language. Try changing your system over to Japanese as the primary language and restart Eclipse. In the N20060608-0010 build, the Ant script wont even run. It says the Ant script terminated, but no output will appear in the Console window. We even go one step further by changing the keyboard input over to Romanji or Katakana by clicking on that American flag in the upper right corner of the iMac. When you do both of those things and reboot your Mac, then you know youre in full Japanese mode. Makes life harder to type though. :) Usually just changing the language in System Preferences > International is good enough. :)
Comment 13 Kevin Barnes CLA 2006-06-12 17:19:10 EDT
Do you have the japanese language pack installed also?
Comment 14 David Rostowsky CLA 2006-06-12 17:26:49 EDT
The Eclipse language pack? No. As far as I know, one doesnt exist for Eclipse 3.2.
Comment 15 Kevin Barnes CLA 2006-06-12 17:38:59 EDT
Is there anything in your error log?
Comment 16 David Rostowsky CLA 2006-06-12 17:50:50 EDT
!ENTRY org.eclipse.ant.ui 4 120 2006-06-12 14:52:27.104
!MESSAGE Error logged from Ant UI: 
!STACK 0
java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
	at java.net.ServerSocket.accept(ServerSocket.java:421)
	at org.eclipse.ant.internal.ui.launchConfigurations.RemoteAntBuildListener$ServerConnection.run(RemoteAntBuildListener.java:95)
Comment 17 Kevin Barnes CLA 2006-06-13 11:32:29 EDT
I can reproduce the timeout exception, but I can't explain it yet. For some reason the ant launch is failing and therefore it never connects back to eclipse which causes the timeout. The strange thing is I can only reproduce this in my host, and not in my target.
For kicks I tried this on linux and everything seems to work fine. I have to admit that testing code on a japanese OS isn't easy for me though. :D
Comment 18 David Rostowsky CLA 2006-06-13 11:51:39 EDT
I'm happy to help guinea pig any fixes you might have on our iMacs in Japanese. Its definitely not easy, but we have translators in house to help when I get stuck. :)
Comment 19 Kevin Barnes CLA 2006-06-13 14:49:47 EDT
Changing the OS language on Mac also changes the default system encoding from MacRoman to SJIS. I suspect that this is causing the problem. Ie, we're creating folders/files in MacRoman, switching the system to Japanese (and SJIS) then trying to read and launch a VM with SJIS encoding.

Unforetunately I don't have the skills necessary to test this. David would it be possible to have one of your translators create a new project on a japanese machine (ie a clean, non MacRoman directory) and try running an ant build in it?

Comment 20 David Rostowsky CLA 2006-06-13 14:57:16 EDT
OK, I should be able to try it out today and let you know how it did. 
Comment 21 Kevin Barnes CLA 2006-06-13 15:01:10 EDT
I should also note that the default encoding would not change if you were to start your workbench with -nl option, and that the default encoding on my linux box is UTF-8 regardless of whether it's running in Japanese or English. Under both these scenarios the test case works correctly.
Comment 22 David Rostowsky CLA 2006-06-13 16:58:52 EDT
OK we started up Eclipse in Japanese so the file encoding was SJIS. Created a new Java project. The project name was all in Japanese. When we created the project the path was in "Macintosh HD"/<Japanese string>/. We copied the previous build.xml over to that directory, did a refresh on the project so the file would show up, and then ran the External Tools on it. Still got the same exception as above. 

Interesting that you mentioned the file encoding being UTF8 working on linux. I tried to force Eclipse to set the file.encoding=UTF-8, but Eclipse seemed to crash. i.e. "./eclipse -vmargs -Dfile.encoding=UTF-8" Hopefully, thats the right way to do that. Eclipse went non-linear and crashed pretty fast doing that though.
Comment 23 Kevin Barnes CLA 2006-06-13 18:00:11 EDT
I didn't use -Dfile.encoding to switch to UTF-8, it's the default on my linux box.  That means that Eclipse and my file system were both using the same encoding regardless of the language. The problem I think we're seeing on mac is that we're creating MacRoman files, then trying to run them as if they were SJIS. I'm not sure what copy/paste does to a files encoding, but I suspect the original encoding is maintained.
Comment 24 David Rostowsky CLA 2006-06-13 18:29:58 EDT
Yea, I had the same thought about the copy/paste preserving the file encoding on the build file. On the Mac, I did save my build.xml as SJIS though. You can verify it in Eclipse too by right clicking on the file and Properties. 
Comment 25 Kevin Barnes CLA 2006-06-20 18:03:28 EDT
I don't think this is an Eclipse bug, but probably a vm bug. Runtime.exec(..) seems to be having a problem launching ant. Similar behavior can be reproduced using a java to launch a python script. All is happy when my OS is english, however, python fails to run when the OS is set to Japanes.


This is my java file. 
public static void main(String[] args) throws Exception {
//		String fileName = "/Users/kevinbarnes/temp/\u3050\u3060\u3070/";
		String fileName = "/Users/kevinbarnes/temp/english";
		Runtime rt = Runtime.getRuntime();
		File file = new File(fileName);
		System.out.println("working dir: " + file.getAbsolutePath() + " exists? " + file.exists());
		Process process = rt.exec(new String[] {"python", "HelloWorld.py"}, null, file);
		
		InputStream in = process.getInputStream();
		for(;;) {
			int i = in.read();
			if (i<0) 
				break;
			System.out.write(i);
		}
		in.close();
		process.getOutputStream().close();
		process.destroy();	
		System.out.println(process.exitValue());
	}

HelloWorld.py is just: print 'Hello World'

Running this code from the command line (ie Eclipse is no way involved) works fine and the python exit code is 0. However, if you change the code to use the japanese directory instead of "english" python process exits with code 255 and nothing is printed to the command line.

Here is my output:

dyn:~/Eclipse/Workspaces/japanese/Junk kevinbarnes$ java RuntimeTest
working dir: /Users/kevinbarnes/temp/english exists? true
hello world
0
dyn:~/Eclipse/Workspaces/japanese/Junk kevinbarnes$ java RuntimeTest
working dir: /Users/kevinbarnes/temp/?????? exists? true
255
Comment 26 David Rostowsky CLA 2006-06-20 18:33:32 EDT
Wow, thats interesting. Not suprising given the weird support for Java on the Mac.  

Does the same failure apply to an Ant script run from the command line?
Comment 27 Kevin Barnes CLA 2006-06-21 17:27:31 EDT
Same result running an ant build. When the OS is set to japanese, the exit code is 255, but when it's english, ant runs fine.

english OS output:
dyn:~/Eclipse/Workspaces/japanese/Junk kevinbarnes$ java RuntimeTest 
working dir: /Users/kevinbarnes/temp/??? exists? true
Buildfile: build.xml

f2:
     [echo] hi

BUILD SUCCESSFUL
Total time: 0 seconds
Exception in thread "main" java.lang.IllegalThreadStateException: process hasn't exited
        at java.lang.UNIXProcess.exitValue(UNIXProcess.java:119)
        at RuntimeTest.main(RuntimeTest.java:24)


Japanese OS output:
dyn:~/Eclipse/Workspaces/japanese/Junk kevinbarnes$ java RuntimeTest
working dir: /Users/kevinbarnes/temp/?????? exists? true
255


Comment 28 Kevin Barnes CLA 2006-06-21 17:29:12 EDT
I'm going to mark this as WONTFIX since it seems that this is not specific to Eclipse.
Comment 29 David Rostowsky CLA 2006-06-22 14:27:17 EDT
Ok, thanks for looking into it. 

Any way IBM can file a bug with Sun to get some traction on resolving this? I imagine theyd respond quicker hearing from Eclipse people than one of the "little" people (i.e. me).