If you take a look at some of the recent reports generated from the usage data collector, you may notice that there are a lot of custom (i.e. not from eclipse.org) views, editors, and perspectives out there, but not so many custom commands.

This is merely my own observation based on what I see in the report (so reality might be different). What I expected to see was a lot more xxx entries (what we use to indicate data collected about non-org.eclipse.* bundles) in the commands table than appear in the others. I expect to see commands being invoked a heck of a lot more often than the various views, editors, and perspectives are opened. But I don’t.

I assume that most folks are running the usage data collector in their development environments (you’d have to explicitly include it in your RCP application’s configuration if you wanted to see it there), which seems to indicate that use of the command infrastructure is very low amongst tool developers working outside of eclipse.org projects.

The reason for this low penetration seems pretty clear to me: the command infrastructure is a little hard to get your brain around (plus it is “relatively new”). There certainly are a lot of questions about it on the various Eclipse newsgroups (like newcomer). From this data, I can see that (a) the Command infrastructure needs to be easier to use, (b) better documentation and examples are required, or (c) both. A small group of us spoke at EclipseCon about writing an article to fill the documentation gaps; or at least to try and bring as many of the pieces together into coherent whole. That effort has taken the form of Bug 223445. Unfortunately, the effort seems to have stalled (as if often the case after the initial excitement wanes). But new life will be breathed into the effort. Oh yes… new life.

The usage data collector is part of the Ganymede packages, so the data that we’re getting is—thus far—only from those early adopters who have been testing our milestone and release candidate builds. It’ll be interesting to see what other information we can glean as more users opt to provide their data.

FWIW, we are very careful to control the kind of data we’re collecting. First, we only capture the names of commands, views, editors, perspectives, and bundles; along with bundle versions. With each data upload, we also capture the country from which the upload occurred. We are not capturing anything of a personal nature. We do not, for example, capture IP addresses, file names, email addresses, the name of your dog, or any other such thing. Second, we are careful about what we report. We’re obfuscating the names of bundles, views, editors, and commands that do not originate from eclipse.org (we also don’t obfuscate the names from the Subclipse and ICU4J bundles).

So… tell me honestly: how do you feel about your Eclipse IDE capturing usage data?

Whenever I think of p2, I just can’t shake the image of the little dog in the stories we used to make up in French class in elementary school. “Pauvre Pitou. Il a sauté par la fenêtre…” But I digress…

Today I did a little experiment with p2. I downloaded one of the Ganymede M7 packages and installed in into a shared location on my file system. This particular system has Fedora 8 Linux installed, so I opted to put Eclipse in the “/opt” directory. Anybody can read from this directory, but only root can write.

I then launched Eclipse as a non-root user and opened the “Software Updates and Add-ons” dialog and added a bunch of stuff from the Ganymede update site. From a user’s perspective, everything just worked. p2 uses some smarts to pick the best mirror from those available, and downloads all the required bits and pieces using multiple threads. Overall, the experience was pretty seamless.

Under the covers, there was more going on. Of course, running as non-root, p2 couldn’t write the downloaded files into my /opt/eclipse/... directory, so it created a hidden directory in my user home, /home/wayne/.eclipse with all the new stuff. It also stores my configuration there.

This is good stuff. If I really was sharing this workstation with others, I’d want to share the bulk of the common plug-ins, but have the ability to customize my own experience by adding my own additional plug-ins without having the custom experience of other users imposed on me. I understand that the p2 framework provides support for updating the shared installation, but this isn’t exposed in the user interface yet. In fact, it probably doesn’t make sense for it to be exposed in the workbench, a separate (perhaps headless) application might be more appropriate for that anyway.

I don’t know if the p2 developers thought of everything, but they sure thought of a lot of things.

I’ve been hacking over the last couple of days on an update to the Understanding Layouts in SWT (the original is here). I’ve had my eye on updating this article for a while, but have been skittish about tackling it because of all the screenshots. Bug 221251 forced me to look at it, and then one thing lead to another, and, well… I wasn’t planning to do anything this past weekend anyway…

To save time and make it easier to rebuild the screenshots if I ever need to, I’ve created a plug-in project that can regenerate them. I intend to put the project somewhere so that it can be shared and used by others (but need to figure out where).

The article was originally authored by Carolyn MacLeod and then updated (for Eclipse 2.0) by Shantha Ramachandran.

So far, I’ve only updated the style of the document to benefit from the new template (and removed all that icky MS-Word markup using a bevy of regular expressions), redid the screenshots and reworked some parts of the format and text. I figure that a full update needs to consider StackLayout and TextLayout, so I plan on spending a few hours working that in later in the week.

In the meantime, if you see anything wrong with the new version, I’d like to hear about it. Add your comments to Bug 221251 (or you can attach them here, but the bug would be a better place).

The first thing I asked about “20 Things” was for the pop culture source of the title. Apparently (according to McQ), there is none.

The first thing that I noticed about “20 Things” was that there are only 17 things on the list (at least there were only 17 when we started).

The first thing that I thought about “20 Things” was that the list provides a good path for introduction to important Eclipse topics. “20 Things” is the list of ~20 things that people building applications on the Eclipse platform need to think about. AFAIK, the fact that—at least the first few of them—are in the order that I introduce them to people.

If you’re just learning to build Eclipse plug-ins, the first thing you need to know is how to build a simple view. The PDE provides a lot of help in this regard. Once you’ve got that view that’s more-or-less independent of everything else in the workbench, probably the next thing you need to think about is the selection service. Shortly thereafter, you’ll need to look into the adapter framework ([1], [2], [3]). Not long after that, you’ll need to think about jobs, help, preferences, etc. Like I said, the list is pretty much in order. At least the first eight or so.

Of course, not every plug-in (or application) has views or a GUI of any sort. So, it’s probably more accurate to say that this list of ~20 things contains those sorts of things that developers building GUI applications based on Eclipse technology should care about. But even for that group of developers building headless plug-ins and applications, there’s still a lot of value on that list.

I’ve uploaded some pictures from the E4 Summit to Flickr.

I sat in on the “Modeling the Workbench” breakout session at the E4 Summit.

Before I go too far, it’s worth pointing out that there is a lot of activity going on here and I’m only able to capture some small part of it. The information that I’m capturing is my perception of what’s happening and may not accurately reflect reality

There is a consensus that a consistent underlying object model is required for the workbench. Currently, at least in the Eclipse platform itself, there is a relatively good ethic of having a user interface model (a là model-view-controller pattern); the problem is that there is little consistency. Each component has a different, custom-rolled model. The notion of a DOM has been discussed heavily. The basic idea is similar to that of a browser: to change what the user sees, you change the DOM. Changes in the DOM are reflected in the user interface. This opens the door to the use of CSS to control of the workbench presentation. Of course, EMF is a great candidate for modeling the workbench. It was discussed, however, that other technologies (including databases) might be considered (or at least left open as options).

One of the more interesting things discussed (and the source of the title of this post; I’ll leave it as an exercise for the reader to find the popular culture reference) is the use of a bus in place of the bajillions of listeners currently used. It’s like a light-weight in-memory version of an Enterprise Service Bus (ESB); though I could see it being a cross-process thing. Rather than setting up many individual relationships between JavaBeans and user interface components, the selection service, part listeners, etc., a small number (possibly one) of buses can funnel changes into a single point. Today, for example, a view will register listeners on the (potentially) thousands of objects displayed in table. Imagine instead, registering a single listener on a bus that will notify you when any attribute in one of those thousands of objects changes. Rather than implementing my domain model as JavaBeans with bound properties, I instead just drop and event on the bus and let it tell everybody who cares. It makes sense. It reduces the amount of work that results from a change (especially if you have a decent filtering mechanism). It simplifies the development model which should lower the barrier for entry to everybody. To boot, by including an ESB, we have greater buzz-word compliance. I wish I’d thought of it.

Remember that these are all just ideas. You need to get involved in this conversation. The E4 page provides some useful links for getting involved including the mailing list, and the IRC channel. Of course, the E4 page is on the Eclipsepedia Wiki, so you can add your input there as well. If you want to check in on the E4 summit, you can connect to the web cam.

After the coffee break, we had a discussion of making resources available for the E4 effort.

Jochen Krause (RT Project Lead, RAP Project Lead) from Innoopract, the major contributor to Eclipse RAP, is dedicating 3-4 developers to the E4 effort. Innoopract is particularly interested in working toward better Eclipse integration on the Web; specifically CSS and Scalability. In keeping with earlier themes, they expect to backport some of the innovations (like multi-user enablement in the 3.x stream).

McQ (Eclipse Project PMC, Platform Project Lead, and more) from IBM reinforced his team’s intent to keep the 3.x stream alive. The Eclipse project is currently gathering requirements for the 3.5 release. His team will contribute a 10-person investment to E4.

A lot of people in the CDT community are interested in contributing to the flexible resources model. Doug Schaefer (Tools PMC, and CDT Project Lead) from WindRiver has volunteered (or was volunteered) to lead the effort. Chris Recoskie (DSDP DD, CDT) from IBM has at least one person who will be working on E4.

Christian Campo (Riena Project Lead) from compeople stated that the goals of Riena are compatible with E4 goals. So while Riena cannot explicitly commit to development resources on E4, developers are working toward similar targets. If development toward this goal fits better in E4 than Riena, then it can be contributed there.

Now, we’re starting some breakouts.

FWIW, we have a webcam in the room. Check-in once-in-a-while to see what’s happening (hopefully server won’t fall over).

I’m at the E4 Summit this morning. I’m completely surrounded by Germans (which is a Good Thing™). To my front is Boris Bokowski of the Platform team (who actually lives in Ottawa). To my right is Jochen Krause from RAP. Behind me is Christian Campo from Riena and Michael Scharf from DSDP. The room is filled with dozens of folks who have come from all around the world to discuss the future of the Eclipse platform. Many of the folks here are committers on Eclipse projects, but some are non-committer representatives from the broader community.

McQ is coordinating things (but is happy to give up the position should somebody else want to stand up in front of everybody) and Kevin McGuire has graciously volunteered to take notes (which you should be able to find hanging off the E4 Summit page sometime later today).

Early on, we captured some areas for discussion.

• What is the goal of E4?
• How do we structure the project (human, code)?
• Work areas listed in the E4 Summit page
• Backwards compatibility and deprecation
  • Backwards compatibility is a core value
• How do we describe E4?
• What are the competitors for E4? What is the “Killer App”?
• What kinds of applications can we not build with current Eclipse technology?
• Investment

McQ presented his initial thoughts about the development effort. To paraphrase (I’m not a particularly good transcriber):

“This is not a sandbox. I intend for everything we do to graduate. We should be working on things that we expect to become part of our mainstream codebase at some point. There is a range of things we should be working on. Some of those things will make their way back into the 3.x code stream. I believe that we will not be able to do everything we want to do in 4.0 in a backwards-compatible way. I hope that we will do something compelling which will motivate the community to move to 4.0. If we are successful, at some point the 3.x stream will die (though we can expect many years of ongoing maintenance before that happens).”

We also discussed (at a high level) some of the key/killer features that we need to consider for E4:

• Size/Scalability/RCP
• Style/CSS/skinning
• Easy to learn
  • API Size
• Web/Internet
• Flexibility
  • resources
  • Style
• Platforms, components
• Productivity

Other (more or less random) thoughts thrown out:

• The web and .Net are competitors to E4.
• Eclipse 3.x is probably a bigger competitor for E4.
• It’s not only about IDEs.
• We’re never going to neglect the IDE-ness of Eclipse. We’re going to self-host development of E4 using E4.
• Applications built on the Eclipse platform shouldn’t look like Eclipse.
• We need a plan for migration/deprecation of APIs spanning a 2-3 year period
• Eclipse is as much of a platform as .Net.
• Empowering a broader range of users/developers to build mashups using Eclipse would be über cool.
• Eclipse offers a powerful and independent API that helps people work, providing long term viability no matter how the technology evolves. We need to move this forward to exploit newer technologies.
• We have a new class of target to support. Maybe all the plug-ins aren’t even coming from the same machine.
• One of the values that Eclipse brought is the integration with existing platforms. It’s going to be the same thing in the browser space.
• What does the world expect from us five years from now?
• We are so successful that people are now building applications that are an order-of-magnitude larger than they were years ago. People are actually building applications with 3k-10k of bundles.

Time for a coffee break. More later.

Well… mostly.

The code for the Eclipse Business Expense Reporting Tool (you may have noticed that I’ve changed what the ‘T’ stands for) has been checked into CVS per the approval of CQ 2310 and subject to the constraints of the parallel IP process.

I don’t consider this a complete example yet. The initial code contribution is only a starting point, and—while I think we’ve made a good start on implementing the values of the Examples project—there’s still a lot of work to do. To start with, there is an embarrassing lack of unit tests. I have added quite a lot of (hopefully valuable) comments, but more are needed. Additional documentation of the architecture is required, along with discussion of some design points, and links to other sources of useful related information. I also have some ideas for simplifying the bits that permit platform-specific (RCP, RAP, and eRCP) customization of the views.

I spent some time yesterday cobbling together a website for the example. The website has instructions (along with handy Team Project Sets) for obtaining the code and rudimentary instructions for setting up your environment to make sense of it all. I have started the process of creating the Bugzilla component for EBERT (Webmaster Matt assures me that the new inbox for the component will be online tomorrow). In the meantime, if you just can’t wait, feel free to create bugs against the “General” component and I’ll move them after the “Expenses” component has been created.

I’ve also requested that the old eclipse.technology.eep newsgroup be retired and replaced by a shiny new eclipse.technology.examples. The mailing list will remain examples-dev@eclipse.org (like most other Eclipse projects, the mailing list is intended for discussion amongst project committers).

Good times lie ahead.

I’ve added social bookmarking to some of the Eclipse Corner Articles. Specifically, it’s been added to the articles that leverage our “new” format. For example:

• Creating Database Web Applications with Eclipse
• Integrating EMF and GMF Generated Editors
• Defining Generics with UML Templates

You’ll (hopefully) notice a small bar in the top right corner of these articles.

I’ve been (slowly) working through updating the older articles to use the new format, so over time more of the articles will have this capability.

Have at it.

Radoslav has taken it upon himself to get EBERT running on Sprint Titan (based on eRCP). How cool is that? Let me answer that for you: very cool.

See some screenshots here. I’m looking forward to Radoslav’s contributions to the project.