New to Eclipse and already having major problems

[Jon Swanson]

I am decided to try using Eclipse rather than vim. I downloaded the latest Kepler release for Windows 7.

1. Created a workspace
2. Created a project
3. Created a package
4. Added external jar files that my package uses
5. Added some entries to PATH that my package needs
6. Ran my application

Everything worked.

Then I was using Green to build some UML diagrams and eclipse locked up. I had to kill it with the task manager.

When I tried to bring eclipse back up, I got the message:

The project cannot be built until the build path errors are resolved

I made the mistake of copying all the external jars into my WorkSpace. That originally was no problem, when eclipse quit and restarted, however, it deleted the directory and all the jar files in it.

According to one post I found on StackOverflow, if I added another jar, eclipse would somehow come to its senses and work again. Well, I decided to delete one of the jars and add it again (after copying the directory back). This did not help. I also tried refreshing, that did not help either.

So I thought I would delete all those added jars. I went to run->Run Configurations->Classpath. Under that I have something called ASAPprime (default classpath), which has all the classpaths under it. But if I click on any of them, eclipse will not let me remove them. So I tried removing the entire ASAPprime (default classpath) and using Add External Jars. After that eclipse is still unhappy. The reason as best I can tell, is that it has corrupted my file paths. For example,

C:\Users\ChemModeling\Documents\FreeThink\Java\ASAPprimeWorkSpace\ASAPprime\classes\lib\PDFjet.jar

was truncated to:

ASAPprime\classes\lib\PDFjet.jar

this did not happen the first time, eclipse listed the whole fully qualified path. However, now they are listed under User Entries and I can delete them individually, for whatever good that does. In fact, when I had the entry ASAPprime (default classpath), all the jar files were in there with the full path, but eclipse did not seem to recognize them.

So I tried moving all those jar files outside the workspace and defining them again. Now all the paths are correct, the error changes to:

Could not find the main class and it is still failing to resolve references to any of the external jar files, even though the paths are now correct.


Could someone give me some idea what to try next? I am not seeing any choice other than deleting the entire workspace, but if every time eclipse locks up I have to start again from scratch, I am not going to see this as a productivity tool.

[Jon Swanson]

I am not sure if this is progress, but I selected Restore default entries. That put my package back on the classpath, it also deleted all the references to the jar files that I had moved outside my workspace and replaced them with the original paths (which I again can't remove). So I once again copied the jar files into the location I started them in (in the workspace) and eclipse decided it was happy again. This time, eclipse didn't delete anything when I exited and started it back up.

So while things are working, since I don't have any feel for why eclipse decided to start generating errors, why it was happy again, or how things should really be set up, all I can do is hope this sort of thing is infrequent.

Again, any suggestions on what went wrong or a better way to set things up would be appreciated.

[Peter Johnson]

Um, what is Green? (I'd google it but...)

It sounds like you might be running into heap size issues. You might try increasing the Eclipse heap size, you can do that in the eclipse.ini file.

Also, much of your post is very hard to follow. For example, you mention "now they are listed under User Entries". Where are you seeing "User Entries"? Given the number of places where Eclipse likes to hide information, I am not inclined to spend a lot of time search for "User Entries". And heaven forbid if "User Entries" shows up in several places and each one means something different. Therefore, it usually helps to specific the menu path that you sed to get to some information.

Finally, your post seems to indicate that you did a lot of things. It is usually easier to help if you stick with the first problem you ran into, some of the other issues might have simply resulted from the first problem.

[Jon Swanson]

Sorry for being confusing, I am not very familiar with Eclipse.

I had been happily using Vim and javac, but have been asked to switch to Eclipse. In my case, I had a package that used a number of external jar files. I kept these in a lib sub-directory of my classes directory along with a bunch of sub-directories of data that I included in my jar file. That made for a pretty simple manifest and it was easy to make and run my jar file.

So switching to Eclipse, I needed to give Eclipse this information. I tried specifying the external jar files of my lib directory by going to Run->Run Configurations... going to the Classpath tab, selecting User Entries and then Add External Jars... for each jar file. The jar files I added show up under the default classpath User Entry. If I select one of the added entries, the Remove option is not available. So I am not sure I used the right procedure to add them.

In any case, Eclipse worked, until Eclipse locked up on me and I killed it (from the Task Manager). After that, Eclipse started complaining about build path errors, would not allow me to remove the previous classpath entries I had added (so I could change the location), deleted the entire library of jar files and generally defied my attempts at understanding any message that it reported. Now it is working again and I don't understand why it started working any better than why it stopped working.

FYI Green is an add-on for generating UML diagrams. Eclipse locked up just after I removed a class from one of Green's UML diagrams. Given that the UML diagram looks fine now that Eclipse has come back to working order. I am not sure Green had anything to do with the problem.

[Peter Johnson]

The classpath for a project is stored in the .classpath file in the main project directory. Eclipse won't show it to you, you'll need a file manager (i.e Windows Explorer) to see the file, but you can edit it with a text editor. Most likely the file got corrupted and somehow at some point was "fixed" - usually making a classpath change in Eclipse causes Eclipse to rewrite the file based on its internal data.

When Eclipse screws up (which it does often, depending on what you do with it), there are usually several things you can try to restore order. You don't have to do all of these, bout one or a combination of a few of them usually gets me back on my feet.

1) Backup the current project (using Windows Explorer) then in Eclipse delete and recreate the file. Then in Explorer copu over the source files again. This is made extremely easy if you follow a directory pattern such as that enforced by Maven - just copy the src directory. Then in Eclipse, refresh the project. 9 times out of 10 this is all it takes. (This takes care of Eclipse screwing up the .project or .classpath files or the .settings directory)
2) In Eclipse create a new workspace. Then follow step 1 to recreate the project. This usually fixes the other 10% of the cases. (This takes care of Eclipse screwing up something in the .metadata directory within the workspace.)
3) Reinstall Eclipse. This usually helps only if a plugin keeps configuration files and the like in the Eclipse installation directory. Plugins aren't supposed to do that, that's what the workspace/.metedata directory is for) but I've seen too many plugins that don't follow this simple run (we are stuck with one such plugin at work).

[Jon Swanson]

Thanks Peter,

I'm a little clearer on how things are arranged in Eclipse now. The entire workspace is actually backed up onto a Linux server every night. I will definitely compare the .classpath files if I see this problem again.

I assume I could make a local copy of the src file, copy the last good workspace from the server and then copy in the most current src files without Eclipse having too much heartache?

[Peter Johnson]

Yes, that should work. Though you should separate the "source" files from the files built during a compile/build. You need to backup only the source files - the "built" files you can easily recreate by doing a build. You really should use a source code repository, such as Subversion or git, to store the source files, that is much preferable to simply backing up the source files; that way you'll also have a history of your changes.

[Jon Swanson]

I'm using Hg for source code control. A lot of what I do has nothing to do with programming and needs nightly backups. The source code goes along for the ride. But it also means I have the other Eclipse workspace files backed up, so I can just copy those files rather than having to configure Eclipse again, if there is a problem. Not to mention all the external jars I'd have to get again if the computer crashed.

Thanks for all the advice about Eclipse.

[Peter Johnson]

You can save your Eclipse configuration to a file: File | Export | General | Preferences
That way when you create a new workspace, you can import to preferences to the new workspace.
I usually have 1/2 dozen workspaces (each with a different group of projects) on my main laptop and I run Eclipse on multiple machines; having the exported preferences file makes it easy to ensure all my workspaces on all my machines are configured the same.

I also hated juggling JAR files, especially the wasted space when each project used almost the same set of JARs. I had innumerable copies of log4j and junit! But now I use Maven for building and never concern myself with JAR files any more.

[Jon Swanson]

Thanks again Peter. I just exported my Workspace. It seems like a generally smart idea.