Monday, November 13, 2006

Remote System Explorer 1.0 is released

The Target Management Project is pleased to announce its first public release: The Remote System Explorer (RSE) 1.0 is now available for download as well as the project update site.

RSE is a framework and toolkit in Eclipse Workbench, that allows you to connect and work with a variety of remote systems, including
  • remote file systems through SSH, FTP or dstore agents (seamless editing of remote files including remote search and compare),
  • remote shell access (compiling with error navigation),
  • remote process handling through dstore agents,
  • and remote debugging through CDT / gdb.
Committers will enjoy the ability to seamlessly work on servers directly from the Eclipse Workbench. Add-in providers can use the RSE framework to contribute their own remote system and connection types. For getting started, please check out the
If you find RSE useful or you find any issues, we'll appreciate your feedback on the newsgroup, developer mailing list or bugzilla. Appropriate links are in the release notes as well as the FAQ.

Wednesday, October 11, 2006

Voluntary but coordinated - release test involving the user community

The Target Management Project started its 2nd round of coordinated testing these days on its first release candidate, RSE 1.0RC1.

The interesting part of this test effort is, that it does not only involve committers but also many users who volunteered to join the testing. It looks like the users understand, that joining a coordinated test early helps each of them by achieving better quality - at little cost if lots of people join. The original test invitation E-Mail had been sent directly to all users we've had contact with, plus the tm-dev mailing list.

The test is mostly facilitated through the Eclipse Wiki as a platform for collaboration, plus daily E-Mails to all signed up testers and the tm-dev mailing list during the test period, mentioning important news.

Some things we have learned from this effort:
  • Signing up each user with a 2-hour effort in advance, and asking them to change the signup on the Wiki themselves proved very effective. That way, we also signed up each user with some randomly chosen feature.
  • It took some time until users learned to use the Wiki effectively. It looks like there was some unnecessary shyness of getting involved and modifying content themselves. The 2nd round of testing is going a lot better than the first one already.
  • Bugzilla was used with a specialized bug entry form, remembered as bookmarkable entry and used by the testers. Having the detailed configuration info at hand with each bug report proved very helpful.
  • We found a lot of new bugs - some of them critical - and surprisingly few duplicates, although we had asked testers to not waste time searching for duplicates before filing a bug. This seems to show how valuable it is to have a large group of testers with slightly different usage schemes, even if each of them invests only a small amount of time (we mostly asked for 2-4 hours each).
Comments from our testers showed that everybody liked the format of this test. In fact, everybody increased time commitment for the 2nd round of testing, and nobody left. At the same time, the users learned about new features and the project found new bugs.

This test is a great example showing that the Eclipse model of Open Source works really well: communities of users, contributors and committers all working together on a common goal, coordinated but voluntary. It shows that Open Source does not mean it is uncoordinated; in fact, by being Open and Transparent the Eclipse model is probably more coordinated and predictable than many proprietary projects.

Thursday, September 28, 2006

Target Management is getting mature

The Eclipse Target Management Project passed its 1.0 Release Review yesterday. Though the slides (PPT | PDF) were not actually presented in the review phone conference, they are an interesting read and outline the state and scope of the project very accurately.

Officially, passing the Release Review means that the project is considered healthy in terms of the communities it has acquired, and that it's been dealing correcly with Intellectual Property: the project is allowed to exit Validation (Incubation) Phase and become an "official" Eclipse Project. As part of getting mature, the project has documented a lot of its processes, which has been helpful for other projects to read, too.

In terms of code, the project delivered RSE 1.0 Milestone 5 last week and has just completed its first Coordinated Release Test. 11 testers from all communities - commiters, contributors and users - took part in this test effort, which was facilitated mostly through the Ecipse Wiki: an approach that played very well and might also stand as example for other projects.

A series of release candidates is going to follow, culminating in RSE 1.0 on October 20. If you'd like to join the test team just make yourself heard on the mailing list!

Monday, August 21, 2006

RSE 1.0 M4 released

The Target Management Project has released milestone 4 of its Remote System Explorer (RSE). The RSE is a perspective and toolkit in Eclipse Workbench, that allows you to connect and work with a variety of remote systems. M4 has been found nicely stable already.

[RSE Sample Screenshot]
What's perhaps most interesting for the average Eclipse user, is a remote file system explorer using the ssh connection type. With it, committers can work on the server just as if it were local - and edit remote files, or use it for uploading.

A remote command shell is also available, providing content assist and output pattern matching for commands like find or grep -n. For generic remote terminal access, the TM project is going to integrate a full-blown terminal emulation in the near future.

Got interested? The RSE works with Eclipse 3.2, or 3.3M1. It is most easily available from our update site at For a minimal install, choose runtime-core, runtime-local and runtime-ssh. Alternatively, you can also get it from the TM download area. A tutorial will guide you through the first steps. We'll be happy to get your feedback as a bug entry or on the mailing list!

Friday, August 11, 2006

Catch me if you can ?!?

I really like the JDT's Java Exception Breakpoints: Most of the time, I'm running my code from the debugger, with breakpoints set at least on NullPointerException and ClassCastException (through Run > Add Java Exception Breakpoint). It brings my debugger exactly to those places where a problem occurs - and helps me to diagnose it right away.

But sometimes, the debugger breaks at unexpected places, like the following code I've seen the other day:
try {
} catch (NullPointerException e) {
//Nothing to execute if foo's not there yet

Apparently, the original developer's idea was that the FooManager might have a foo or not -- if it doesn't have one, then getFoo() returns null and there is nothing to execute.

Now most seasoned Java Hackers may have it in their guts that this is not good code. The younger ones might know it because Bloch writes it (Effective Java, chapter 8, Item 39: Use exceptions only for exceptional conditions; if you haven't read this book, you must read it!).

Bloch has some good arguments for avoiding exceptions instead of catching them. But using exception breakpoints, here is another just practical one - it breaks the debugger where it's not necessary, because the code does run as intended. So I've changed the code:
Foo foo = FooManager.getFoo();
if (foo!=null) {

Now that's even shorter (4 lines of code instead of 5), clearer to understand, and my Debugger won't need to get active... so in the future, I'll live with Catch me if you can't avoid me - which might have made the life of Tom Hanks easier too...

Friday, July 21, 2006

Networking Eclipse

Gee so here I've got my own blog after all. Networking Eclipse, you might think, what does that mean? And what is tmober?

In the Target Management Project, which has been an Open Source Eclipse project since May 2005, we are working on frameworks and software tools that help developers handle remote (networked) computers.

So that's where tmober comes from - initials for Target Management, with the first four characters of my surname. Though you could read the m for Martin as well - or the t for ... (well, your choice, I'm thinking).

Working on an Open Source software project has a lot to do with communications - and involves a lot of the other networking, the social one. I hope that this blog will contribute to some thoughts picked up by our community, fostering networking in many aspects.