Home About Eric Topics SourceGear

2007-11-28 17:58:33

From C# to Java: Part 4

As a member of Microsoft's VSIP program, we have been creating source control plugins for the Visual Studio line of products for eight years.  As I started my recent foray into the Eclipse world, I was eager to explore the area of plugins over on this side of the fence.  So far, I'm impressed.

Source Control and Bug Tracking

The first plugin I installed was our own.  SourceGear Fortress includes an Eclipse plugin, but I had never even tried it.

My first reaction is that I really like the way Eclipse handles installation of plugins.  The whole process is managed from within Eclipse itself.  Under the Help menu is a submenu called Software Updates.  All I have to do is provide the URL of our Eclipse update site:

http://download.sourcegear.com/Fortress/latest/update

The rest of the job is very simple, essentially automatic.

Once installed, I have several additional views:

And some new stuff under the Team menu:

And some new items under Preferences:

All in all, I have found using source control under Eclipse to be very pleasant and straightforward.  If this seems like I am bragging about my own product, I suppose it is, except for two mitigating factors:

  1. I personally had nothing to do with this plugin, so this is less of a boast and more of a compliment to the efforts of my coworkers.

  2. In my experience, source control plugins are a lot like children.  To some extent, the behavior of a child (or plugin) reflects the quality of the structure and guidance provided by the parent (or IDE).  In saying that our source control plugin works very well, I am complimenting Eclipse.

Truth be told, I did find [what I think is] a bug in our Eclipse plugin.  Fortunately, because Fortress supports integrated bug-tracking, I was able to use the plugin to report the bug right from within Eclipse.  :-)

CheckStyle

In part 2 I complained about the way Java handles object comparison (== is for identity, .equals() is for state).  I received quite a few comments and emails for that one.  I don't mind the contrasting points of view, but I'll confess I deleted all the remarks from condescending nitwits who assumed I simply don't understand pointers.  :-)

Anyway, several people suggested I try an Eclipse plugin called CheckStyle.

Once again, installation was extremely simple.  After that, I immediately ran CheckStyle on my code, just to see what happens with no further configuration.

CheckStyle complained about the 301 places where I put the curly brace on the next line:-)

Overall, CheckStyle looks very cool.  I'll be experimenting with it more and configuring it to match my coding style.  I don't expect I'll make the == mistake again now that I remember how Java does things, but it's nice to know that if I do, CheckStyle can pester me about it.

The Ecosystem

The VSIP people are always talking about the Visual Studio "ecosystem", the collection of organizations creating every conceivable type of plugin for Visual Studio.

The corresponding ecosystem for Eclipse appears to be enormous.  When I Google for the words "eclipse plugin", the top two hits appear to be sites which are trying to help people find plugins.  One of those sites is www.eclipseplugincentral.com, which seems to be saying there are 991 plugins in its directory. 

I know for a fact that there are at least 992, because the SourceGear Fortress plugin isn't listed yet.  :-)

Browsing the directory reveals an incredible diversity of plugins.  Many of them are unsurprising, but the fringe cases suggest just how large the surface area of this ecosystem really is:

In fact, as I looked through this list of plugins, I started to realize that Eclipse is basically a modern Emacs.  The true die-hard Emacs users want to do everything within Emacs.  One of my coworkers likes to edit /etc/passwd and set emacs to be his shell.  Eclipse seems to be heading in the same direction.

Bottom Line

I've tried 2 Eclipse plugins so far -- 990 to go.  This should be fun.