I have a project in eclipse that contains an ant build.xml file. Whenever I double click the build.xml file to open it, eclipse hangs. I can leave it for hours and it never does anything. When it's hung it isn't using any cpu and doesn't appear to be doing anything. Eclipse version is 3.5.2. I downloaded the latest version, installed it, created a project and pulled in my files and the same thing happened there as well.
So, I tried a different project. When opening the build.xml the same thing happened - it hung. I tried going to Windows\Preferences\Ant\Runtime just to see what was there, but it hangs when I click on Runtime.
I can open any other file - xml files, properties files, java files, etc.
Any ideas on what I can do to get this working again? It used to work - it's only recently that it stopped working. I don't know what to do to try to resolve this.
Can you open the build.xml file with some other editor? (Right-click on it in Eclipse, choose Open With and pick an editor other than the Ant editor)
I suspect that either the workspace is corrupted or the ant editor is corrupted.
To check for a corrupted workspace, open a new workspace and create a project with a build.xml file and see if you can edit it. If you can, copy all your projects to the new workspace and then import them into Eclipse.
If that does not work, I recommend you reinstall Eclipse; that will be much faster than trying to figure out what the problem is and fixing it.
Before you do either of the above, export your preferences so that you can import them into the new workspace.
I already tried both. I created a new blank workspace, imported my project and when opening the build.xml eclipse hung.
I also reinstalled eclipse - the latest version and imported my project and the same thing happened.
I can open the build.xml in notepad and it all looks fine.
I'll try going with a new workspace, new project and new build.xml and will see what happens.
posted 8 years ago
It appears that something in the preferences must be corrupt - is that possible? It all works fine if I create a new workspace. I can copy in my project and the build.xml opens just fine. As soon as I import my preferences, everything breaks again. I have so much 'stuff' customized in my workspace I don't think I'll ever get it back where I need it again. :-(
Sounds like a problem that hit me just the other day. Apparently there's some "snapshot" files in the metadata that can cause long/infinite delays when something goes wrong. Deleting them fixed my problem without having to nuke the entire workspace metadata.
You might want to google for that, since I don't remember where I got that info from.
An IDE is no substitute for an Intelligent Developer.
posted 8 years ago
OK. I started with a clean Eclipse workspace, pulled in my project. Everything was OK and my build.xml file was opening just fine. I reset all my preferences (all the ones I could think of anyway) and at some point, it happened again. I can no longer open it without hanging Eclipse. Obviously, something I'm setting is messing things up but I have no idea what it could be. I'm not changing any ant specific settings in the preferences. I'm setting a few content type/file association things and setting some Tomcat server settings. This is going to drive me crazy!
posted 8 years ago
I still can't get it to work. I've uninstalled, reinstalled, used a clean workspace, an old workspace, with preferences and with no preferences set and I can't get it working at all now. Could there be something on my PC interfering (port issue, driver issue, etc). I'm grasping at straws.
Is there another ant plugin (other than the one that comes default with Eclipse) that I could try using instead?
I know that this is an old thread, but I am currently having the same issue. Eclipse just hangs if I run the ant build script, or try to open the build file with the ant editor (plain text editor is ok), or if I try to open Window->Preferences->Ant->Runtime.
I tried the obvious things like creating new workspace or fresh install of Eclipse, but it doesn't help. It happens even if I create a blank build.xml file and I try to open it with the ant editor. The command line ant build works fine.
I was wondering if you found a solution to your problem.
Do you have CLASSPATH set to anything? Is there anything in your JVM's "endorsed" directory? I suspect a stray class/JAR is causing this problem.
One way to check if there is a stray JAR is to edit the eclipse.ini file, adding the line "-verbose:class" to the end of the file, and then run the eclipsec.exe (the console version of the executable) from the command line, redirecting stdout and stderr to a file:
eclipsec > eclipse.log 2>&1
The -verbose:class option causes the JVM to print the location of the JAR file for each class loaded. Look for classes that were not loaded from either rt.jar, or from a JAR within the Eclipse directory.
Also, did you do any updates within Eclipse? If so, I recommend reinstalling. Updating Eclipse has caused way to many problems that i no longer do it.
Thank you Peter for your reply. I already tried with fresh install of Eclipse, but it didn't help. This thing used to work, and it stopped at some point.
I have two java directories D:\Java\jre6 and the jdk one D:\Java\jdk1.6.0_27. My JAVA_HOME variable is set like this:
When I ran the eclipse with the -verbose:class parameter in the eclipse.ini file as you suggested I noticed that the java classes were loaded from D:\Java\jre6\lib\rt.jar and not from D:\Java\jdk1.6.0_27\jre\lib\rt.jar
The strange thing was that when I was running eclipse.exe I had the ant problem, but when I was running eclipsec.exe I didn't have the problem with ant.
I made the following change to eclipse.ini, I added these two lines before the -vmargs:
And now both eclipse.exe and eclipsec.exe work, and the java classes are loaded from D:\Java\jdk1.6.0_27\jre\lib\rt.jar
Eclipse doesn't use the JAVA_HOME setting. Instead it uses the java.exe at c:\windows\system32, and that java.exe uses the registry to determine where the rt.jar is located. And as you noticed, Eclipse wasn't using the JVM you expected. And your solution is the correct one. In fact, I always set -vm in my eclipse.ini (which makes things fun when I upgrade to a new version and he old one is no longer there...)