The Eclipse Target Management Project just released its M6 Milestone (downloads | update site). Given that you have Eclipse 3.3M6 installed, it will also be available from the Europa Discovery Site shortly.
Top news besides lots of refactoring and API cleanup is that the RSE Eclipse Filesystem (EFS) integration has been promoted from "experimental" to "stable". It allows taking any remote file system available through RSE (like the ssh, ftp and dstore connections) and making it available as resources in the Eclipse Workspace. By sitting at the heart of the Eclipse Resource System, the full power of Eclipse - including source parsers, outline views, content assist and the like - comes to remote files as well.
Although quite a few EFS implementations have been around so far, Target Management / RSE is the first one that solves the problem of logging in to remote systems and keeping credentials in a usable UI. We'll continue working on the integration as described on plan item 170916 in order to iron out final issues and further improve performance.
EFS is a great concept of making the Eclipse Workspace more flexible, but components and plugins need to be aware that the resources they work on can now be remote as well. Work is going on through Platform Plan Item 154126, similar work items in CDT and other tools to improve their EFS integration. Up to now, however, this work has been hard tue to a lack of good EFS implementations. We hope that the new Target Management / RSE EFS implementation will help foster the adoption of EFS in the committer and plugin provider communities.
If you want to learn more about the Eclipse Target Management Project, your perfect choice of getting first-hand information about it is the upcoming Webinar hosted by the Eclipse Foundation on Thursday April 12 at 8am PDT / 11:00 am EDT / 3:00 pm UTC. In 45 minutes, you'll get an intro on the TM concepts and architecture, see an online demo, learn about upcoming plans, and get the chance to ask the TM project leads any questions you have.
Note added on 17-Apr-2007: The TM EFS Provider was fixed later in order to resolve issues running out of handles on SSH connections. These fixes were released as TM 2.0M6a. Users who already downloaded M6 can easily update out of Eclipse: Choose Help > Software Updates > Manage Configuration, find the "Remote System Explorer" feature, choose Scan for Updates.
Tuesday, April 10, 2007
Friday, March 16, 2007
TM / RSE Usage Survey
Every product needs to know their users. Thus I'm conducting a survey of companies and products that plan to adopt Eclipse Target Management / RSE in the next year or use it already.
Both commercial products and in-house usage are interesting.
If I have not contacted you directly yet, and you do use or plan to use TM / RSE, please drop me a short E-Mail at
martin.oberhuber (at) windriver.com
I'd like to know your company name and a very rough outline of what you're doing (or planning to do) with TM / RSE. Knowing our users will certainly help our community, thus product quality and also help initiate the next release cycle's planning process, so it's also for your own benefit.
Thanks!
Both commercial products and in-house usage are interesting.
If I have not contacted you directly yet, and you do use or plan to use TM / RSE, please drop me a short E-Mail at
martin.oberhuber (at) windriver.com
I'd like to know your company name and a very rough outline of what you're doing (or planning to do) with TM / RSE. Knowing our users will certainly help our community, thus product quality and also help initiate the next release cycle's planning process, so it's also for your own benefit.
Thanks!
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
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.
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.
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:
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.
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).
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!
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]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_sgEP9ZP3073mzcDCgg9X_FXqN9A85GhEdg0bCaJ0540xU95RQwuDr_3JSgWPkD9YYoCF3giXqmAOEO8vNwzDrUUa7a-7ehp60wJGqdOhyUuauGlkfSgs_0=s0-d)
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 dev.eclipse.org 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 http://download.eclipse.org/dsdp/tm/updates: 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!
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 dev.eclipse.org 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 http://download.eclipse.org/dsdp/tm/updates: 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
But sometimes, the debugger breaks at unexpected places, like the following code I've seen the other day:
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
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:
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...
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 {
FooManager.getFoo().execute();
} 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) {
foo.execute();
}
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...
Subscribe to:
Posts (Atom)