Eclipse Irritations: .classpath and Phantom Ctrl-Shift-T

At work, the de
facto
IDE is Eclipse. It
seemed like a good idea to check in the .classpath file
— where Eclipse stores all the JAR dependency information for your
project — and there haven’t been that many problems.

Checking in .classpath Stinks

However, when .classpath problems do happen, things
blows up big time. My advice is don’t check that bugger in:
the path system in it isn’t general enough to be group-usable, and CVS
conflicts are just annoying to deal with when they happen.

Loosing Ctrl-Shift-T

Needless to say, I had some .classpath problems today,
and in the process of “fixing” it, I must have re-jiggered some
internal source indexing in Eclipse. As a consequence of whatever I did, I
lost the ability to use the “Open Type” functionality over my own code
base: you know, that nifty little “open up the source for this class”
dialog that you get when you do Ctrl-Shift-T. Sure, all the classes
from my JARs were in there, but none of my project’s high quality code!

To fix it, I closed the project, and then re-opened the
project. Then, when I did Ctrl-Shift-T once again, Eclipse seemed to
be building back up it’s index, and everything was hunky-dorey.

Butter

In closing, yes, I know: if I used only emacs or vi or Notepad or
JEdit or NetBeans or whatever your super-dope IDE is I wouldn’t have
any problems. I’d also have fresh butter churned up for me every 30
minutes. I just don’t have the need for that much butter.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.