Unshackling Mylyn from the Desktop

Next week at EclipseCon, I'll be giving a talk with Gunnar Wagenknecht on our side project to bring a hosted task list to Mylyn. This is something that I'm really excited about and it will be the first time we are discussing this project in public. The Mylyn project was a truly ground-breaking project when it first became an Eclipse project back in 2005. It revolutionized the way that developers work with and manage the over-abundance of information in the IDE. Now, even though it is still a well-used and loved project, it has not been evolving at the same rate that developers' expectations have. Since being introduced, developers tend to be less tied to their IDE, using git on the command line, github in the browser, and email on a tablet. However, the Mylyn task list is stuck in the IDE.

In our presentation, we’ll be demoing a hosted task list, that can gather tasks from multiple task repositories (Jira, Bugzilla, etc), store them on a server, and then provides an open API to interact with them. The API is open, using a mix of REST and websockets, and this is the interesting part since the API allows you to build clients that interact with your task list in ways that were never possible before.

If you’re interested, I hope you’re coming to EclipseCon so you can see our talk. If not, you’ll have to wait until later when I have some time to write a proper blog post about this.

Where's the memory leak?

A few days ago, I was tracking down a memory leak through Yourkit and I was pointed to this code (vastly oversimplified, but just complex enough to prove my point):



This code is part of a compiler and stores some metadata on an Abstract Syntax Tree node during byte-code creation. The profiler told me that there were thousands of ClosureWriter instances being kept around for the length of the compile (roughly one for each closure defined in the program). While not a huge amount of memory, this bothered me. For a while, I couldn't figure out why these references stuck around. Then it occurred to me that each reference to ClosureWriter.UseExistingReference.class keeps a back pointer to the enclosing ClosureWriter instance. By changing the UseExistingReference to static, the leak disappeared.

What's the lesson?

In Java, always, always declare your inner classes as static unless you are sure that you need back references to the enclosing instance.

What is this cloud thing?

Here are the slides from my UBC alumni presentation on programming for the cloud.



You can also download the demo code that I wrote during the talk here on github.

Thank you all who came. It was a lot of fun to give the talk.

Lots of beer, pizza, and coding

Lots of beer, pizza, and coding. I'd say that our second Vancouver Eclipse hackathon was a huge success. We had committers from several Eclipse and Eclipse based projects: Mylyn, p2, JDT, Orion, and Scripted were all represented. We had 30 hackers spread across all of these projects. Currently, we have 7 patches that have been accepted into codebases, and three more that are working their way through the submission process.

The hackathon was a great and social way to be introduced into the open-source world and perhaps some of these new Eclipse contributors can become Eclipse committers. If you are interested in holding an Eclipse hackathon (or any hackathon) in your area, feel free to contact me. I now know what works and what doesn't.

Just getting started

All working hard

Nieraj and Leo take a moment to relax

Ian Skerret, flew all the way from Ottawa for us

A big thank you to all the project leads who helped (and are still helping) some newcomers fixing their first bug. And an even bigger thank you to everyone who worked hard and stayed up late, just to do some coding. It was a lot of fun.

For another look at the hackathon and more photos, see the Tasktop blog.

JSDoc is more than just documentation (in Scripted)

Recently, we released the Scripted editor for editing your JavaScript. It's still early stages, but our focus on a light-weight and semantically aware editor already has some compelling features. In this blog post, I'll show you how you can use JSDoc in your JavaScript files to provide Scripted with some inferencing help. Since Scripted uses the Orion editor, most of this JSDoc support is also available in Orion.

There are many flavors of JSDoc and there is no standard, but the Google Closure Compiler uses a style that is well-documented, self-consistent, and complete. We use Doctrine as the JSDoc parser, which has a complete understanding of the JSDoc annotations of the Closure Compiler.

Currently, Scripted recognizes a subset of JSDoc tags:

• @type {type-sig} {optional-doc} specifies the type of a variable declaration
• @param {type-sig} {param-name} {optional-doc} specifies the type of a function parameter. Parameter annotations are not positional. They must correspond to an actual named argument of the function.
• @return {type-sig} {optional-doc} specifies the return type of a function

The docs for the Closure Compiler specify many kinds of type signatures. Only a subset are relevant to and supported in Scripted. Scripted recognizes:

• Simple types, eg- {Window}, {boolean}, {Boolean}
• Record types, eg- {{myNum: number, myObject}}
• Function types, eg- {function(arg0:string,arg1:boolean)}
• Function return types, eg- {function():number}

And of course, type signatures can be combined to produce more complex signatures. The built-in types boolean, number, string, and object can optionally be capitalized, this breaks from the semantics of the closure compiler, but provides more flexibility to programmers. Other kinds of signatures are tolerated, but do not affect the inferred type.

Examples

With this information, we can start showing some examples. Scripted uses typing information for hovers, navigation (e.g., CTRL+Click to navigate to definitions), and for content assist.

Simple @type

Here is a simple JSDoc comment to define a string variable:

Record types

Using a record type signature, you can define the type of an object literal:

Functions

You can specify that a variable is a function, as well as include its parameter names and return types (parameter types are currently ignored for function type signatures). It looks like this:

If you want to declare the types of function parameters, then you should be using the @param annotation, like this:

User defined types

User defined types are recognized as well:

Union types

One possible point of confusion is with union types. They are interpreted by Scripted as whatever the first signature is. So, in the following is interpreted as a string:

Node support

And finally, Scripted's JSDoc support can be combined with its dependency analysis to infer types defined in other modules. This is extremely helpful for node projects where the use of callbacks can obscure the parameter types. In the following example, by specifying the types of the req an res parameters, you can get some meaningful content assist for them:

What's next

There are some more interesting cases that we should handle. A common idiom in JavaScript is to declare constructors using qualified names. Libraries like Dojo and Ext JS. For example, you can define a class name in Ext JS like this:

Ext.define('scripted.Widget', { ... });

And in Dojo:

var Widget = dojo.declare('scripted.Widget', [], { ... });

We could accomplish this using the @typedef annotation or possibly the @constructor annotation.

Additionally, the @lends annotation provides a nice way to specify options and configuration for constructing types and will likely make it into an upcoming version of Scripted.

So?

Using JSDoc in your JavaScript files is a good way to give some extra help to the inferencer, which often has trouble recognizing some of JavaScript's more dynamic features. Scripted is still in its early stages, and is moving ahead quickly. We like feedback. You can send a message to the Google group and fork us on Github.

Using Groovy-Eclipse to make your DSLs more friendly

Here are slides and source code for my talk at GR8Conf US 2012. The source code and slides are available as a zip.

You can also access the slides and source code from the GR8 Conf US 2012 github repository.

To play with the sample projects and DSL descriptors, you should start with a snapshot version of Groovy-Eclipse 2.7.1 and import the two projects from the zip file into your workspace.

The best place to get your questions answered is on the Groovy-Eclipse mailing list.

(Slides) Light-weight IDE extensibility for custom DSLs in Groovy

Here are my slides from my EclipseCon 2012 talk, Light-weight IDE extensibility for custom DSLs in Groovy.



Update: Uh-oh...looks like the conversion to slide rocket didn't work quite as well as I would have hoped and the animations as well as some of the text is missing. I'm going to see if I can get something better up here.

Light-weight IDE extensibility for custom DSLs in Groovy

This post gives a bit of a teaser for my EclipseCon talk next week.

Most of you reading this probably know that Groovy-Eclipse is the Eclipse tool support for Groovy and one of the major features it provides is type inferencing in the editor. For example, in the following screenshot:

Groovy-Eclipse knows that the type of myString is java.lang.String. That is why substring is not underlined, but uh_oh is. All references that cannot be statically resolved are underlined regardless whether or not the program will fail at runtime (Groovy is a dynamic language, and we can't be certain about what happens at runtime).

This works quite well in common situations. However, things get complicated because Groovy provides strong support for creating domain specific languages (DSLs). Typically, when a DSL is used, the editor will be confused. Consider, for example, this simple DSL to calculate distances and convert between units. When used in Groovy-Eclipse, the result looks like this:

Uh-oh, underlines. The references do not make sense to the editor, even though this executes without problem.

Thankfully, Groovy-Eclipse's inferencing engine was designed from the beginning to be extensible. There are three ways to extend the inferencing engine:

1. Roll your own Eclipse plugin
2. Inferencing suggestions
3. DSL descriptors

And I'll talk about each of them in the next sections.

Roll your own Eclipse plugin

This is a powerful technique and gives you fine-grained control over exactly how your DSL integrates with Groovy-Eclipse. I have already written a full description of all the extension points available and how to use them to create a plugin that extends Groovy-Eclipse. This was the state of Groovy-Eclipse circa 2010.

Although there have been many successes with this approach, we found that overall this was quite a heavy-weight way for others to leverage the benefits of type inferencing:

• Most Groovy DSL developers are not Eclipse experts and so do not have the experience or desire to learn Eclipse APIs, create plugins and features, produce an update site, and test it against various versions of Eclipse
• Many Groovy programmers (the ones who consume the DSLs) are coming from a scripting world, use vi or textmate, and are used to a light-weight editor. Installing plugins was a big complaint for them. They want things to just work

Clearly, another approach was needed.

Inferencing suggestions (very light-weight extensibility)

Inferencing suggestions give the end user control to augment the inferencing engine with specific suggestions. Using a quick-assist (CTRL+1), the user is given an option to add a suggestion to the currently selected identifier in the editor:

This brings up the inferencing suggestions dialog, where the user can fill in as little or as many details as desired:

And now, back in the editor, the suggestion is now used for inferencing:

This feature has some big advantages over the plugin model:

• it gives end-users more control over their own environment
• it is dead simple to use and no other plugins are required
• no need for any Eclipse API knowledge
• little knowledge of Groovy required

But in some situations, this feature moves too far in the direction of simplicity over expressiveness.

• can only target a single property/method at a time, which makes large DSLs painful to work with
• not easy to share across users and projects

Inferencing suggestions was not sufficient and we needed yet another kind of extensibility.

DSL descriptors (light-weight extensibility)

A DSL descriptor (DSLD) is a Groovy script that describes your Groovy DSL. This script is compiled and executed by Groovy-Eclipse so that the inferencing engine can understand the DSL. They can be shipped with libraries and as long as Groovy-Eclipse can find these files on the classpath, they can contribute to type inferencing. I have already written a good introduction to DSLD.

We created the DSLD language so that library developers could have fine-grained control over how their library and DSL gets interpreted in Groovy-Eclipse and also so that end users can transparently use this functionality without needing to install a new plugin or do any extra work.

Taking our distances DSL from before, we can write a simple DSLD that encapsulates the DSL in a format consumable by Groovy-Eclipse:

contribute( currentType( subType( Number ) ) ) {
  [ “m”, “yd”, “cm”, “mi”, “km” ].each {
    property name:it, type:"Distance”, 
        doc: """Converts a {@link Number} to a {$it}
                @author Joe
                @since 1.0"""
  }
}

When this file is saved to something like distances.dsld and placed in the project or on the classpath, the distances expression is appropriately recognized in the editor:

(Which, you should notice looks the same as the inferencing suggestions hover above.)

What kind of extensibility is best?

That's a loaded question and of course, it depends. Here's a simple table to highlight the costs and benefits of each approach:

	Extension points	DSLD	Inferencing suggestions
Ease	heavy-weight	light-weight	very light-weight
Flexibility	lots	some	little
Eclipse knowledge required?	lots	none	none
Groovy knowledge required?	lots	lots	little
How to use/install	update site	included with library	preferences/quick-assist

I'd still recommend that you come see the talk at EclipseCon (if you are lucky enough to be attending the conference). I'll go into more detail on implementation and I'll show some live demos on how this all works. See you at EclipseCon!

Better JavaScript content assist in Eclipse Orion

Even in the month since I started using and working on Eclipse Orion, there have been significant improvements to it. The UI is getting cleaned up, navigation is getting easier, git integration is progressing, and search is improving. It's great to be contributing to such a fast moving project, even if the rate of change can be dizzying sometimes. Also, I'm new to JavaScript and I have never worked on such a large code-base written in a dynamic language. One of the things that I have been missing the most is good tool support that really knows about the code you are working on. Traditional IDEs set the bar high in this area.

I'm happy to introduce a small step in the direction of making the JavaScript editor smarter. I've just released an Orion plugin that provides semantically aware content assist in the JavaScript editor. The plugin uses the Esprima JavaScript parser with some extra error recovery added by Andy Clement. I have found the Esprima parser to be fast, clean, and easy to use and using it as the core of the content assist plugin has been the right thing to do, even though this project, too, is fast moving and hard to keep up with.

How it works

Like content assist in Java editors in Eclipse, the Esprima content assist plugin is based off of a semantically rich abstract syntax tree (AST) and so content assist proposals are more likely to be relevant than if we were using a lexical approach to content assist. Here is what happens:

1. On a content assist invocation, the contents of the buffer are parsed by Esprima.
2. The resulting AST is walked by the content assist plugin.
3. While walking the AST, the target type of any AST node is recorded as well as assignments and declarations. This information helps us keep track of what properties are available on each known type at any given point in the AST.
4. After walking a sufficient amount of the AST (we don't need to walk the entire tree since parts of it are not going to be relevant for a given content assist invocation), all available proposals are calculated based on the target type of the invocation offset and the prefix.

The best way to understand how this works is through examples.

What it can do

Recognizing function scopes

As you can see in this screenshot, scoping is respected and identifiers that are not accessible in the current scope (vInnerInner, v3, v4,…) are not shown in content assist.

Object literals

The key/values of object literals are appropriately proposed:

Even nested object literals are recognized:

Simple control flow

Simple control flow is recorded by the plugin, so that assignments are remembered:

Pre-defined types

Some (but not all) predefined types are available in content assist.

Currently, the plugin recognizes JSON, MATH, Number, String, Boolean, and Date, but I will probably add more as it makes sense.

Constructors

Functions that start with capital letters are considered constructors

Parser recovery

Finally, Andy Clement has been doing some work on making the esprima parser recoverable from errors. Actually, some error recovery is already in esprima, but we need to tweak it a bit for content assist. Hopefully, this work can be contributed back to esprima after we have a good solution. Currently, the recovery work is focussed on errant dots. A common case is that you will type a variable name and then a '.' and expect content assist to provide all reasonable answers. Most JavaScript parsers will fail after the first error, which makes them quite useless when editing code.

As you can see in the screenshot, despite all of the funky dots, the plugin is able to realize that myVar is of type Number and is providing appropriate proposals.

What it can't do (yet)

This is still early for the content assist plugin and there is quite a bit of work to do. For example:

1. There is no pre-defined window object, which probably should be there, along with possibly other predefined objects, like dojo, dijit, and $ (jquery).
2. There is no analysis of function return types
3. No inter-file type inferencing, which will be crucial for getting anything really smart working
4. The plugin should recognize /*global */ comments
5. The Esprima-based proposals are currently intermingled with proposals from the default JS content assist plugin and so duplicates appear. (Esprima proposals are always prefixed with a handle (Esprima) so you know where they come from, but they are always on the bottom).

I hope to deal with each of these issues eventually, but I also need to make sure that performance remains reasonable, which it currently seems to be, but is something I need to watch.

How to get it

Mark Macdonald has already added the pluign to the Orion plugin page, so after you log into Orion, click to the "Get Plugins" link and select the Install link for the Esprima content assist plugin:

The github page is located here: https://github.com/aeisenberg/esprimaContentAssist so try it out, have a look at the code and let me know what you think!

First ever Vancouver Eclipse Hackathon...success!

Last night we had our first Vancouver Eclipse Hackathon. It was a wonderful night, and we had 20 Eclipse hackers showing up with all kinds of experience. The goal of the evening was to introduce some programmers to Eclipse-based open source projects, to help them collaborate and learn about the project, and maybe even contribute some code. Some hackers had written Eclipse plugins before, others knew nothing about Eclipse (other than it being a great Java IDE), and a few didn't even know Java. It was a good range of people and we spent almost six hours working on our bugs.

Working on quick-assists inside of Groovy-Eclipse

Team working on mark-occurrences in the Groovy editor.

Some Mylyn Hackers working together.

More hacking.

Almost complete silence in the room as everyone concentrates on their bugs.

Happy birthday, Eclipse!

And here are the results of the evening:

• 20 hackers (including two project leads)
• 6 hours of hacking
• 24 bottles of beer drunk
• 6 pizzas eaten
• Half of an Eclipse 10 year birthday cake eaten
• 3 Eclipse-based projects worked on: Mylyn, AJDT, and Groovy-Eclipse
• 12 bugs worked on
• 3 patches submitted
• 2 more patches in process
• Fun had by all

It was encouraging to see the dedication of all the hackers. We will definitely be hosting another one soon. However, we did learn a few things about organizing hackathons that we will do differently next time:

• Make it easy for hackers to set up their dev environments. Put up instructions a few days before so hackers can get ready before the hackathon and they don't have to spend 90 minutes setting up before starting.
• Internet connections can be unreliable and slow. Have USB sticks available with Eclipse SDK tarballs for different environments. Also, have some workspaces set up with the source code of the projects checked out.
• Try to have more projects and more project leads available. This time, we only had three projects and two project leads, but more variety would have been nicer. We were originally expecting more leads to show up, but they had to cancel.
• Have a very concise list of bugs for hackers to work on. Be very specific about how to get started working on them.

Also, a huge thanks to the other co-organizers of this event Ducky Sherwood and Zoe Jong from Tasktop Technologies.

If you want to organize a hackathon in your area, drop me a line and I can help you get started. It is a fun time.

Using Grails 2.0.0.M2, Cloud Foundry and the SpringSource Tool Suite

There are a lot of details in my VanDev talk tonight. Since most of what I showed you was from versions of our software not yet officially released, you are going to need to cobble together a few things to get everything working properly. Here are some instructions and links.

1. First, here is a detailed guide on using Grails 2.0.0 from inside STS. It was written for M1, but it is essentially the same. Below, I'll summarize.
   
2. Download STS 2.8.0.M1. To see 2.8.0.M1, you need to click on Other downloads.
   
3. After downloading and unzipping/installing STS, you will need to install Groovy-Eclipse and Grails Tooling. Do not install Groovy-Eclipse or Grails from the dashboard since that only points to older releases. Instead, go to the Install manager (Help -> Install new software...), and add the nightly update sites for Groovy-Eclipse and Grails Tooling:
   
   • Nightly Grails Tooling update site:
     http://dist.springsource.com/snapshot/TOOLS/nightly/e3.7
   • Nightly Groovy-Eclipse update site. Make sure to also install the Groovy 1.8 compiler:
     http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
     
   Use these sites to install the software.
4. Next, download Grails 2.0.0.M2.
   
5. Once downloaded and unzipped, you can install the Grails distribution into STS.
   

If you want to play around with Cloud Foundry:

1. First install the CloudFoundry tools from the STS dashboard.
   
2. Then sign up for a CloudFoundry account.
   
3. There's lots of information on the cloudfoundry.com site as well as the community site. Here's more on using Cloud Foundry in STS
   

Here is some more information on DSL Descriptors in Groovy-Eclipse, and also a general description of our approach to integrating the Groovy and Java compilers inside of Groovy-Eclipse.

Support

If you have any questions of problems with STS or Groovy-Eclipse, please visit the forum. However, Groovy-Eclipse questions may be answered more quickly on the mailing list. Bugs can be reported here: Groovy-Eclipse and STS.

AJDT 2.1.3 Released

The AJDT team is proud to release AJDT 2.1.3. This release is the first one targeting Indigo (Eclipse 3.7) and it contains AspectJ 1.6.12.M1. The update sites are here:

For Indigo:
http://download.eclipse.org/tools/ajdt/37/update

For Helios:
http://download.eclipse.org/tools/ajdt/36/update

Please send any feedback to one of the mailing lists or raise an issue
on Bugzilla.

Groovy-Eclipse 2.5.1 Released

The Groovy-Eclipse team is proud to release Groovy-Eclipse 2.5.1. This release is now available for install using the update sites here:

for Eclipse Indigo:

http://dist.springsource.org/release/GRECLIPSE/e3.7/

for Eclipse Helios:

http://dist.springsource.org/release/GRECLIPSE/e3.6/

In this release, we have continued to work on our DSLD support (and we
ship with some useful DSLD scripts). Additionally, we have a GA
release of the groovy-eclipse-compiler-plugin for Maven. Now that
Indigo has been released, the 3.7 stream of Groovy-Eclipse will become
the main development branch. For now, we will continue to support the
3.6 stream of Groovy-Eclipse and will put out at least one more
release.

You can find all the details at our New & Noteworthy page.

Please send feedback here or raise an issue on our issuetracker.

Vancouver Eclipse Demo Camp 2011

In honor of the Indigo release of Eclipse, I will be hosting the annual Eclipse Demo camp in Vancouver on Monday, June 27. The demo camp is co-sponsored by the Eclipse Foundation, VMWare, and Tasktop.

We're expecting a full house as well as lots of exciting talks, including one on Groovy/Grails support in Eclipse and the SpringSource Tool Suite, a talk from Tasktop, and a talk about the Eclipse Modelling Framework from Ed Merks, the project lead.

If you are in the Vancouver area and interested in attending, please add your name to the wiki:

http://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Indigo_2011/Vancouver

Alternatively, contact me directly (or on this blog) and I'll add you myself. Hope to see you there!

Slides from Gr8conf Europe 2011

Here are the slides from my Gr8Conf Europe presentation.

Better DSL Support for Groovy-Eclipse

View more presentations from Andrew Eisenberg

Unfortunately, the animations didn't make the conversion to SlideShare, but these slides will give you an idea of what I talked about. I can also post the sample projects that I showed during the talk.

Groovy-Eclipse 2.5.0 Released

The SpringSource Tools Team is proud to release Groovy-Eclipse 2.5.0. In this release, we are most proud of our new DSL Descriptors (DSLDs) feature, which provides scriptable support for custom Domain Specific Languages in the Groovy Editor. Additionally, this release includes Groovy 1.8 as an optional add on, better content assist and type inferencing, and a Groovier outline view.

See all details on the New and Noteworthy page, and please send your comments to the mailing list. Enjoy!

Better DSL Support for Groovy-Eclipse

What have I been doing lately? Mostly working on Groovy-Eclipse's new DSLD feature to support custom Groovy DSLs more easily. See my post about that on the SpringSource blog.

Next month at the GR8 conference

The nice folks organizing the GR8 Conference 2011 Europe have posted an interview they did with me. You can read it here. The GR8 conference focusses on the Groovy eco-system including Grails, Gradle, and Griffon.

I'll be talking about Groovy-Eclipse, Grails tooling, and our new Gradle support for Eclipse. More on this soon...

Groovy-Eclipse and AJDT simultaneous releases

Today, we have just release Groovy-Eclipse 2.1.2 and AJDT 2.1.2. By coincidence, they both have the same version number.

Groovy-Eclipse

We've made lots of improvements to Groovy-Eclipse including inline renaming support, mark/find occurrences as you type, and type inferencing improvements. You can find all the details at the New and Noteworthy page.

The update site for installation on Eclipse 3.6 is here:

http://dist.springsource.org/milestone/GRECLIPSE/e3.6/

We are also now releasing a Groovy-Eclipse for Eclipse 3.7 (Indigo). The update site is here:

http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

As always, please raise bug reports and enhancement requests at our Codehaus issue tracker.

We expect to release Groovy 1.8 support shortly.

AJDT

Our enhancements for AJDT have mostly centered around supporting Intertype Inner Types. a new AspectJ language feature. You can read about it at the AJDT New and Noteworthy.

An AJDT release for Eclipse 3.7 is available at this update site:

download.eclipse.org/tools/ajdt/37/dev/update/

Please raise bugs and feature requests at Eclipse's bugzilla.

eGit in practice

I like Git in theory. Distributed version control has many advantages over non-distributed including local branching, easier task switching, and easier offline work.  However, as an Eclipse user, I find it highly disruptive to drop down to the command line whenever I need to perform any git commands.  Despite its advantages, using git instead of CVS or SVN has felt like a big step backward because of its lack of Eclipse tooling.

Until now, I have only been using git occasionally, and so I could live with the inconvenience.  However, it looks like some of my major projects will be moving to git and so I need to figure out what to do.  I have been eagerly awaiting the eGit tooling to reach a reasonable level of maturity.  I decided to try it out and see how far along it is.

Install and setup

I installed eGit 0.11.3 from the public repository (http://download.eclipse.org/egit/updates) into my SpringSource Tool Suite.  And as expected, the Git Repository perspective was initially empty.  So far so good.

I thought I'd start by cloning the SpringIDE project.  Initially, I tried right clicking in the Git repositories view, and expected that I'd be able to pasted the repository URL directly.  That didn't work.  There is only one option: to paste an existing repository path:

Instead, I used the "clone repositories" command button.  I was able to do what I wanted to, but it was slightly less intuitive than I would have hoped.

Using eGit

After cloning, Git placed the entire repository on my hard drive, which is nice because checking out, exploring, and comparing is much faster than using a traditional VCS.  Performing these operations within Eclipse is just as speedy as doing things like comparing local history.  At this point, I was very impressed.

Then I made a single change to a file and things started going downhill.  After the change, I had to wait about 30 seconds for the '>' to appear in the package explorer next to the changed file (whereas with Subversive and the CVS tooling, this happens what seems like instantaneously):

Then I started playing around... I right-clicked on the file I had just changed and selected Assume unchanged.  Uh-oh!  ClassCastException.  Now, click Assume changed.  IOException.  Apparently, though something worked and I was able to continue with the commit and then view the commit in history.

Next problem: I moved back to the Git Repositories perspective, and I had lost all of the git repositories in the git repositories view.  Re-importing them would not work.  It looked more like the UI had crashed than any data had been lost:

I restarted Eclipse and everything seemed back to normal:

Despite its problems, eGit has a good UI.  The project is clearly following the Eclipse User Interface Guidelines, and I was able to easily transfer my familiarity with Eclipse's CVS and SVN tools to working with git.  This is a strong indicator to me that the project is headed in the right direction even if it is not quite there yet.

And so...

The basic features that I need exist, but after 20 minutes of using, I hit several obstacles.  None of them were insurmountable and the project is usable.  Despite this, I do expect that future releases will be significantly more solid.  I will likely be using eGit for my day to day work, but for now this will be largely for repository and history exploration, rather than for commit and branch management, which I'll probably use the command line for.

---

EDIT: I raised Bug 339158 and Bug 339159 to track some of the problems I found.