I've been using an ever larger number of Eclipse plugins in my development. I'm using Jetty Launcher, Maven, AJDT (AspectJ), Oxygen (XML editor), Subclipse (SVN support), TestNG, and a few lesser ones.
Eclipse is pretty good about backwards compatibility, so I've tried just switching my eclipse folder from 3.1 to 3.2. Should be new JARs against my existing workspace and we're off and running.
No such luck. I was working on that yesterday and I quickly got to a point where I could not convince Eclipse 3.2 to even try and compile my code. It's on the class path, I can see the class files in the package explorer, but no dice on compiling.
My sneaking suspicion is that it's the Maven 0.0.9 plugin (this plugin keeps Eclipse dynamically up to date with your project's pom.xml).
So I downgraded to Eclipse 3.1. Guess what? No dice there either.
As you might imagine, this put me in a bit of a panic. I tried deleting my project and checking it back out of the repository. Still no dice. The panic level increased again.
My final solution was drastic: delete my workspace entirely. Eclipse stores considerable meta data about your project outside the folder itself. In the shuffling up to 3.2 and back to 3.1, some amount of that has been corrupted.
It's not so bad ... it's now spring cleaning time as I'm starting from an entirely fresh Eclipse install and even re-downloading just the essential plugins that I need.
6 comments:
When you get to Subclipse, note that we have a version specifically for Eclipse 3.2 that is worth getting:
http://subclipse.tigris.org/callisto.html
When the workspace gets corupt, sometimes a -clean at Eclipse startup will clean up the coruption. I highly recommend using -clean after upgrading major plug-ins as well.
I'm building up on Eclipse 3.2. The Import functionality is able to do a good job of copying my old projects into my new workspace.
I usually leave all the projects outside Eclipse workspace, so no need to copy anything and you can quickly import them to any workspace as long as you have .project and .classpath files.
Yes, I always have a c:/workspace directory, seperate from my c:/eclipse directory (holding my head in shame as a windows user). In any case, the problem was in c:/workspace/.metadata.
It seems likely to me that Christopher's solution, the -clean option (which I didn't know about, or had forgotten) would have helped. Now its too late to find out.
Spring cleaning is not a bad thing.
I routinely create a new revision of the workspaces to go with the new version of the IDE.
I typically have c:\eclipse-installations\3.1
c:\eclipse-installations\3.2
and workspaces
c:\eclipse-workspaces\3.1\work1
c:\eclipse-workspaces\3.1\work2
c:\eclipse-workspaces\3.2\work1
c:\eclipse-workspaces\3.2\work2
This allows me to try upgrading and experiment with the new version without breaking my old spaces. Some brilliant guy posted the idea on his blog moons ago and it has saved me lots of time.
Post a Comment