Groovy Nature Locks Jar Files in Eclipse Project

For the past few months many of us have been struggling with an issue where we can’t Get Latest on Jar files stored in TFS when using TEE (or Teamprise). The issue is that TEE can’t overwrite the local file because the file is locked by Eclipse. (non-Windows users would not see this as Mac and Linux platforms use a more passive file locking strategy.) On the surface, this issue seemly looks like an issue with the TEE plug-in. However, in these file locking cases, we’ve found that other plug-ins are actually the culprit.

While we’ve been able to reproduce the issue commonly, we’ve finally got some conformation from codehaus.org that the Groovy plug-in many of you use will cause this issue. The root case is that they use the URLClassLoader from Sun/Oracle which won’t release locks on jar files when loaded to the classpath. Or something like that.

Here is a link to the issue we submitted. You can follow that for updates to the plug-in. Hopefully they have this fixed in an upcoming release. Until this time, the best way to work around the issue is to temporarily remove the Groovy Project Nature from your project, do Get Latest, then add the Groovy Project Nature back in.

Remove Groovy Nature = Right Click on Project | Groovy | Remove Groovy Nature

Add Groovy Nature = Right Click on Project | Configure | Convert to Groovy Project

Custom Response Header For Our TFS 2010 App Tier Farm

I’m curious to see if people think this is a good idea or not. In our TFS 2010 farm we have four application servers. In the process of testing load balancing and fail over, I was having trouble trying to figure out which box my requests were going to. Our load balancer sets a cookie so we persist to the same App Tier machine, but it’s an obfuscated value that no one seems to be able to provide any insight into how to un-obfuscate it. (And I’m not sure if devenv.exe is passing that cookie as we seem to be bouncing across all four App Tiers when doing things like “Get.” Not a big deal, but it would be nice if there was a way to persist.)

To help me out, I set a custom response header called “x-tfs-machine” that resolves the name of the App Tier machine. Via Fiddler or Wireshark, I know can inspect what App Tier I’m hitting. It seems to be working quite well for me.

While I’m just using this for testing, I’m thinking about leaving it on when we go live so we can see what server a user is hitting if they are running into issues.

Team Explorer Everywhere Options for Users Wanting a Standalone Client

We’ve had some users who have shied away from using Eclipse plug-ins and have become comfortable with Teamprise Explorer (aka Fat Client). When Team Explorer Everywhere (TEE) was launched, Microsoft discontinued delivering the Fat Client. Thus, those users have continued to use Teamprise. We’d like to get those users cut over so Brian has showed a pretty good work around that should work for these users. Here is what we sent to our teams:

If you’re used to using the Teamprise Explorer for development, here are some options you have when migrated to Team explorer Everywhere (TEE).

1) Switch to using the TEE plug-in in Eclipse.
2) Use the free Team Explorer plug-in to the free Visual Studio 2010 shell. (This only works for Windows users)
3) Per Brian Harry’s post, use the Eclipse Platform Runtime Binary standalone client.

If you decide to go with the last option, here are some general instructions for using the Eclipse Platform Runtime Binaries.

1) Download and install Eclipse Platform Runtime Binary- Install TEE
2) Window Show View Other Team Foundation Server Team Explorer
3) In the Team Explorer panal, select the Add Existing Team Project dialog button
4) Add your server and connection information
5) Select Team Projects you’re involved with
6) Double click on Source Control to get the friendly Source Control tree view
7) Get yourself a cup of hot coffee