This week we have gone through the creation review for Eclipse IAM (Eclipse Integration for Apache Maven), and so we are starting with the paperwork at the Eclipse Foundation to create the project in the incubator and start moving the code from Q4E, the codebase will be donated to IAM as start point.

Development won't stop in the meantime and we don't expect any interruption for Q4E users.

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.

Its the first time since Eclipse 2.x in which I am debating giving up even trying an Eclipse RC version such as Eclipse 3.4RC1. One last attempt now going to enable the classic updater and attempt an install that way with all the 3rd party plug-ins. Sorry folks, I wish I had better results and I do not.

The start of GSOC coding phase is getting closer and closer, so I started examining and debuging the Eclipse source. I'm beginning to understand how all the code generators work, although not without problems. The most difficult for me is the dialogs part - I would say that a little refactoring should be done here. Anyway, it's just GUI so I think it won't be so hard to handle it. As for the code

I received this screenshot from Scott Lewis from the ECF team:



"Eclipse community hard at work on e4"

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.

Event Date: May 27, 2008 4:00 pm GMT-8

Register Now

 

Abstract:

Designing and developing systems based on a Service Oriented Architecture (SOA) involves different approaches and perspectives ranging from process definition to individual service construction and architectural composition. The Eclipse STP top-level project provides several editors across the SOA space, including BPMN, BPEL, SCA, JBI, JAX-WS and Policy editors. Each editor covers part of the specification of a complete SOA system and it is essential that there be a consistent approach to unify all these parts into a coherent whole.

This webinar will introduce you to the STP Intermediate Model (STP-IM) component, a recent addition to Eclipse STP. STP-IM is meant as a "bridge" between editors. Its elements have the role of conceptual transport between different development spaces with the purpose to capture as much common SOA design information from different editors as possible. In particular, it aims to bridge the workflow and process world (BPMN / BPEL) with the architecture specification world (SCA / JBI) and the service creation world (such as JAX-WS). After a brief overview of the STP-IM structure, the webinar will continue with a practical demonstration of how the STP-IM can be leveraged when developing SOA elements with several STP editors.

9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT - Convert to other time zones

Total running time will be approximately 1 hour

Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.

delicious | digg | dzone

I just made new release of SWTBot - 1.0

Direct download link: http://sourceforge.net/project/showfiles.php?group_id=188411&package_id=220519&release_id=601136

Update site: http://swtbot.svn.sourceforge.net/svnroot/swtbot/artifacts/1.0.0/update-site/

Some features:

• A recorder API — now you can record SWTBot scripts. Still in beta though.
• Better SWTBot integration in eclipse — now you can run tests within eclipse.
• More API — now you can use more SWT controls using an even richer API.
• More stable than before.

For more details, you can read up on the release notes here.

Bookmark to

As I noticed the increasingly heavy load on the Eclipse Build server, I looked at my calendar and realized we are in the final month before Ganymede, this year's annual release train. The locomotive is pulling the latest and greatest from superstar projects, such as Eclipse 3.4 (featuring the awesomeness that is p2), Webtools 3.0, CDT 5.0, Birt 2.3 and ECF 2.0.

These next 30-some days are my personal favourites (and likely Kim's favourites too!) as release engineers build continuously, genie spends her time signing JAR files, and our servers take a beating serving bits, updating bugs, committing files and sending mail.

Let the party begin, I say.

The EclipseCon 2008 survey results are collated and online. Go there to read all the details, or enjoy the short and sweet summary: "people were more than 'very satisfied'" with EclipseCon.

I am on my 5th reinstall of Elcipse3.4 folks since yesterday. One of the problems seems to be how major Eclipse plug-ins by-passed normal Eclipse operation. Listen up, for all major plug-ins that require the -clean command in Eclipse 3.3 install as a drop-in. The regular Eclipse EquinoxP2 operation does not put update site to plug-ins as downloading to the dropins folder.

To migrate those plug-ins you will have to select a small group an drop in dropins folder and than boot up Eclipse 3.4 and repeat that process until you have all legacy plug-ins installed in the dropins folder. No, I have to figured out how to get Acceleo modules loaded yet, but do not install those modules via EquinoxP2(ie the non-dropins folder way) as you will end up with a non-update-able Eclipse install(after installing Accelo Modules clicking the Software Updates will state an error as in cannot update) .

Sorry Eclipse team, it needs work and most of that work is from plug-in authors abusing the -clean command rather than doing it an approved Eclipse way and thus you can understand the frustration of Eclipse committers when users complain about this as it somewhat not their faults.

In fact I would suggest that you do a separate folder in dropins folder just for all plug-ins that use the -clean command so that you can migrate those plug-ins for use in Eclipse 3.4.

However those early adopters taking the plunge now, the Ganymedede download links are here. The proper load/install sequence is:

C++
GMF
Models
Enabling
Java
OtherTools
Programming
Remote
Test
Web
SOA
Charting
Uncategorized

I should have more about my plug-in migration steps this afternoon.

With all the good / bad and the ugly posted about p2 lately, I thought I would share a positive experience I had today with Eclipse, Modeling and p2.

It all started when I saw a new video about ECore tools. If you haven't seen ECore tools, and you are a fan of EMF, you really should check it out. (It will likely be featured in my Ganymede Top 10 List). After the video I decided to take ECore tools for test run.

1. Grabbed the latest Ganymede milestone for modelers.

2. I launched Eclipse and tried to create an Ecore Diagram (using Ecore tools)

Problerm: the Ganymede package for modelers doesn't contain ECore tools.

3. I launched Help->Software Updates and searched for ECore tools



4. Ok, no ECore tools... So I selected "Manage Sites" and selected the Ganymede Site



5. Now when I search for ECore tools, p2 returns some Installable Units



6. After selecting Install, and accepting the license, Eclipse suggested I restart



7. And in less than 5 minutes, I was up and running with ECore tools.



While I realize that there are still bugs / features / requests outstanding, this was the first time in all the simultaneous releases that it truly felt like I could just point at a piece of software, and have it up and running without worrying about dependencies, 3-5 minutes to load the UM, broken connections, etc...

I know p2 doesn't work for everyone, but the negative comments often seem to overshadow the positive ones, so I thought I would share with everyone the good experience I had.

Note: I did not write this to start a war, or downplay the problems people are having; this was simply my experience today.

I just saw a press release fly through my inbox from Express Logic.

Express Logic, Inc., the worldwide leader in royalty-free real-time operating systems (RTOS), announced that it has joined the Eclipse Foundation, an open-source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle.

"We’re excited to become part of the open-source community through membership in the Eclipse Foundation,” commented William E. Lamie, president of Express Logic. “Our initial impression has been outstandingly positive, and we’ve been greeted with offers of cooperation and assistance from the community that are most refreshing. Our initial efforts have already resulted in the introduction of a commercial product based on Eclipse, our BenchX™ IDE, which has recently won awards from VDC and eg3.com. We plan to work with the other members of the Eclipse Foundation to help strengthen the Eclipse ecosystem with our particular emphasis on benefits to embedded developers."

One simple scenario for all you “I like to just unzip stuff” people out there, who don’t want/need p2’s ability to resolve dependencies a la Synaptic / apt-get / yum. If you find the new p2 UI is overkill for your needs, you can still kick it old-school:

1. Download the latest Eclipse SDK or EPP bundle
2. Download your add-on SDKs, eg., EMF, Mylyn
3. Unpack Eclipse into your folder of choice, eg., ~/eclipse/eclipse34/
4. Unpack your add-ons into the dropins folder, eg. ~/eclipse/eclipse34/dropins/emf/, ~/eclipse/eclipse34/dropins/mylyn/
5. Start up Eclipse. p2 will discover anything you’ve added in the dropins folder, and load them up. To remove extensions, just remove them from the dropins folder. That’s it!

You can also combine zips with update sites for a more complex install, like for installing PDT 1.1 from a Nightly zip + the Ganymede update site.

Of course, if you have issues w/ the new p2 UI, report it! Over 600 squashed bugs this year alone…

After taking a break from reading the Planet this past week, tonight I discovered several p2-bashing posts. Now, I admit, in December I had some less-than-positive things to say about p2, but that was over 5 months ago. It's been evolving rapidly ever since, and has one of the most responsive dev teams I've ever had the pleasure of working with.

Some statistics, to prove my point:

• 695 resolved Equinox.p2 bugs; 472 open Equinox.p2 bugs. Closure rate: 60%. Given the oldest changed bug is in February, that's over 200 features and work items a month for the past 3 months! (A bug is not always a problem. I use bugs as TODOs, thanks to the wonderful workflow integration provided by Mylyn. But I digress.)
• Of the 20 Equinox.p2 bugs I've opened; only 5 remain. Closure rate: 75%.
• Of the 39 Equinox.p2 bugs I've opened, commented on, or am watching; only 8 remain. Closure rate: 80%.
• Articles in the Eclipse Wiki related to p2: at least 46
• Time required to go from knowing nothing about p2 metadata to having it enabled for all the Modeling projects' update sites and integrated into automated promote scripts: about 2 hrs
• (Recently) active committers for the whole Equinox project: 14
• Lines of code committed in Equinox project in the past year: 378,000
• Number of commits in Equinox project in the past year: 28,000

Bottom line? Ask (early) and ye shall receive. Wait to complain when there's no time left in the cycle, and ye shall be disappointed. This is open source, people. You get back what you put in.

The e4 summit is coming up end of this week and as I was preparing my position paper for it, I pondered the question,

“What should Eclipse look like?”

I then realized that Eclipse shouldn’t look like anything! It’s like asking, “What should a web page look like?”. Different web pages, geared towards different communities, have very different looks. Even within a specific area like B2C e-commerce, Amazon pages have a recognizable style and interaction which at a glance fundamentally differentiates them from say BestBuy.

However, when I survey the set of Eclipse applications they all at a glance yell “Eclipse!” more than they yell their respective companies or domains. That’s not through some kind of laziness or lack of caring on the part of the developers.

Eclipse started out as an IDE. Many decisions were burned in early on. Due to either API compatibility or preconceptions which now put blinders on us, we’ve not strayed all that far. We’ve grown some Presentation level APIs for doing small things like deciding tab style (one of two, you chose!), hiding perspectives, etc., but these have been added piecemeal in reaction to specific community requests. So we’ve been able to open things up a little, but relatively speaking, its still a pretty closed world. Any variance you see is mostly a testament to the incredible determination on the part of application/RCP developers.

At the platform level, updating the look of Eclipse ends up being fantastically controversial, and not surprisingly, given that every change on the glass we make, no matter how small, decides what every Eclipse application looks like. Its close to impossible to make the right decision for so many different kinds of applications and users. But that puts us on the path of least resistance, which means things stay the same. As time goes on, Eclipse is looking rather, well dated. To change things, we will need to see some fundamental shifts in the Eclipse frameworks and components.

I am therefore very excited about the possibilities in e4. The summit has some great topics listed, like:

• Declarative UI
• Styling/CSS
• Modelling the Workbench
• Rich Client Platform

My hope is that in the future, there will exist graphically rich, subtly styled, dare I even say sexy, Eclipse based applications where the only place they reveal their Eclipse technology basis is in the About.

I have been slowly working on bug #197728, which is about adding more personal information into the Portal. A while back I added support for longitude/latitude data and just this week I got around to adding support for uploading an image. The next step in bug #197728 is to develop a web API to make some of this information available for mashups (like a map of where everyone is located).

So, for those of you who want the world to know what you look like or where you are, this feature is for you. Everyone else can just keep coding.

After EclipseCon 2008 and the E4 noise I started to rewrite the prototype shown there to use an EMF-Model (I'm going to refer to this prototype in the rest of this posting as PROTOTYPE_1).

It was quite cool to get insights into the platform code and with the code already created for EclipseCon it was not really an achievement to get something running within a fairly short time but finally I wasn't really happy because of multiple things:

• I had to work around problems from the beginning to get a workbench up and running


• It was hard to add new features because I was limited to things I could find a work-around for or going to learn the complete platform code which would have driven me mad


• There was lack of feedback on the real code and we talked more about EMF pros and cons than concentrating on how we want to solve things (I'm still an EMF believer :-)

• How can I get up an Workbench-Window without any of the legacy code


• How can I easily add features


• How can I encourage people to work on E4 without having a deep understanding what's going on inside the current platform. In fact how can I get people outs