[Eclipse] Superclass does not implement the ‘junit.framework.Test’ interface

I ran into this really strange error the other day while using Eclipse. I had been creating some JUnit tests, and everything was going just fine. Then I tried to create another one, and I saw the dialog below with the error message, Superclass does not implement the ‘junit.framework.Test’ interface.

Eclipse 'Create JUnit Test Case' error screenshot

The JUnit JAR file was in my classpath, so I was befuddled for a minute or two. After searching around I discovered that I had accidentally deleted the JRE System Library from my project Java Build Path. After I restored that, everything worked fine.

The Democrats Delayed My Paycheck and the President May Delay My Project

Strange, but absurdly true. If it were only one of the two delays, I’d skip it, but both is just too odd to pass up.

I work for a national company. I made a request to change my direct deposit setup a while back. I was told by our local branch that headquarters had received the request and would process it. My next deposit was barely half of my regular paycheck and I had no idea what happened. It turns out that the payroll processing is done in Boston, and my request happened to be processed around the time of the Democratic National Convention, where traffic was so bad that people were either not going to work, or leaving early, or whatever. So the second half of my paycheck was delayed a week because the Democrats had a party. If it weren’t so funny I’d probably be a bit annoyed.

Now, I can understand one political event having outrageously insane odds of actually affecting my work life, but two events is just plain weird. Today I discovered that our current project may be delayed becuase of the upcoming US presidential election. We’re sending a mailing out to our customers, giving them a yearly statement, and the two week window that it’s been planned for probably won’t work for the mailing vendor — they’ll be sending out 6 million political mailings for both candidates, and do we really want our clients’ statements to get lost in that mess? No.

Whatever the outcome, I’m ready for the political hoopla to end. I need to get my work done, something they’re not likely to understand.

[Eclipse] More success with standardizing team plugins

I recently wrote about standardizing Eclipse plugins across your team by using a shared Eclipse product extension. We had to do a few things this morning that we hadn’t yet tried since we set this up about a week and a half ago, and it worked out great.

We upgraded our common Subclipse plugin from 0.9.13 to 0.9.16. This turned out to be a really bad idea (not to mention the maintainters are losing my respect), so we backed it out and reverted to 0.9.13. The only thing we had to do was re-enable that plugin on some developers’ Manage Configuration screen (watch out — disabled plugins aren’t shown by default, but you just need to click a button on the toolbar to make them show up again).

We also promoted a plugin from my personal plugin area up to the unstable area. Within 2 or 3 minutes, the move was complete and everyone had the new plugin that wanted to use it. Piece of cake.

We even had a guy move to Eclipse 3.1 M1 last week by simply copying the links folder to his new Eclipse directory as discussed in my other entry. It worked like a charm, and all he was up on 3.1.

So continued experience with this plugin setup seems to be quite favorable. Let me know how you’ve shared or standardized Eclipse plugins in your group.