A few weeks ago Google announced their WindowBuilder contribution to the Eclipse Foundation. The WindowBuilder was originally created by Instantiations and moved to Google after they swallowed Instantiations back in 2010. Anyway, the WindowBuilder is a first class visual editor for creating UIs and will be maintained by Google. It contains an Editor for three UI toolkits: GWT, Swing and SWT. And the coolest thing about the WindowBuilder is that it’s completely open source because it’s an Eclipse project now.

So, you probably know that there is a Rich Internet Application technology under the umbrella of Eclipse too. It’s called Rich Ajax Platform (RAP). RAP provides the SWT API which is also used within Eclipse. As a result, theoretically it should be no problem to use the WindowBuilder’s SWT Designer to create RAP applications and with it a Rich Internet Application. Today I found some time to check it out and I’m happy to say that it works like a charm.

All I had to do was create an Eclipse Plug-In project, change the dependency from org.eclipse.ui to org.eclipse.rap.ui and I could start designing my UI.

On the screenshot above you can see my little experiment. It’s an SWT Shell with a group box and some TabItems filled with random Controls. One nice feature of the SWT Designer is that it provides a preview of the UI. So, the UI will look very similar to the one on my Mac below.

The next step after designing this UI (I know it’s really a masterful work ) was to create a RAP launch configuration that would start the application in a browser. And poof, there it was: a RAP application completely created with the WindowBuilder.

I don’t know if the Google guys know this, but their WindowBuilder actually supports 4 UI toolkits. The three mentioned above and RWT, the SWT port for RAP.

To try it yourself,  I recommend that you download the latest Eclipse package containing RAP from here. After installing you can use the WindowBuilder’s software site to install it into your IDE.  You can use my example project which already contains a launch configuration (don’t forget to switch your target before launching.)

Have fun clicking the UI together .

Tags: google, instantiations, rap, ria, rich internet applications, swt, swt designer, visual editor, windowbuilder

For anyone who follows the Eclipse developer mailing lists, you might notice the weekly e-mails regarding the tagging process. The e-mails usually describe which bundles have been tagged and which changes are included in the build.  In this post, I’m going to describe a little more about this process and why it’s important to the Eclipse build.

Types of Builds:

Before we start, it’s important to understand the types of Eclipse builds. During normal development (not including the maintenance stream) there are two types of Builds. There are builds from head and integration builds.

The builds from head happen every night.  These can be considered the continuous builds and help ensure that our day-to-day work is not breaking the build. Since the build take several hours to complete, it’s impractical for Eclipse to run Builds on Check-In, so instead, Eclipse builds from head once a day. These builds are not really meant to be consumed by users.

The integration builds happen once a week (usually on Tuesday morning) and are built from tags.  The advantage of this approach is that you must explicitly tag your changes for them to be included in an integration build.

Bundle Versions:

If you have ever looked at set of plugins that make up your Eclipse install you will notice that the version numbers are all over the map.  It is well known that Eclipse uses a 4 part Version number scheme (Major.Minor.Service.Qualifier), and the first 3 parts evolve as the API changes.  The forth part (Qualifier) represents the CVS tags.

So this brings forth the obvious question: if Integration builds are built from tags, and the code is tagged once a week, why don’t all the bundles have the same qualifier/tag?

The answer is simple we only tag bundles that change.

Bringing it all together Releng Tools:

If you are doing Eclipse plug-in development with CVS as your SCM, you should be using the Eclipse Releng tools.  It doesn’t come included in the SDK, but you can install it from the Eclipse update site.

Using a map file, releng tools will automatically determine which bundles have changed since the last time they were tagged:

Show you what has changed:

Generate release notes:

And re-tag the bundle(s):

Eclipse tags are often (but not always) in the form: vYYYYMMDD-HHMM. I tend to use the Ottawa date and time (which is three hours later than my current time) — So no, I wasn’t up until midnight on valentines day tagging p2. The only real requirement is that tags / qualifier move forward in time.

Why go to all this trouble?

The biggest advantages of only tagging bundles that change is that unchanged bundles will have exactly the same version number. This means that when you update Eclipse (from week to week) you only need to download the modified bits Let me state that another way (because it’s important): if you update Eclipse and only 4 of the 500 bundles have changed — p2 will only download those 4 bundles.

This approach also enables re-creating an exact build. All you need is the map file, and you’ll have the full list of tags that constituted the build.

Finally, in CVS, tagging is considered a slow operation.  By having each team tag their builds, and by only tagging the bundles that changed, the workload is both reduced and distributed.

Tags: releng

38 days left until EclipseCon — Sure, you’ve registered, booked the flight and hotel, checked your passport. Next: pack your running shoes!

Continuing the annual tradition started by Darin, we are organizing another edition of the EclipseCon Exercise:  an easy 3-mile run, starting in the Hyatt Lobby at 7:00 am each morning, Monday to Thursday. The trail is flat and paved and follows the stream / bike path behind the Hyatt.

Some reasons to run with us:

• have fun and enjoy the fabulous Californian weather
• burn off  last night’s food and beverages
• network in an informal setting
• get an EclipseCon 2011 runner’s shirt courtesy of EclipseSource

If you plan to join us, please RSVP on wiki.

Here’s a picture from last year’s group. I hope to have as many join in this year.

See you in Santa Clara,
Elias.

Tags: eclipsecon, events

When you face the task of building a Server-Side Equinox or a RAP application (which is just a Server-Side Equinox application) you need to choose a build system from a fairly diverse palette. This choice is never easy because every build system has its pros and cons. In the end it comes down to which one you and others, love or hate.

To make this task a little easier we created a small github project called “RAP build examples”. It provides examples of how to build a RAP application with different build systems. Currently the following systems are covered:

PDE Build:

The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server). read more…

Tycho:

Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles. Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGi bundles with Maven. Eclipse plugins and OSGi bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. read more…

WAR Products Tooling:

The WAR Products are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. read more…

All the examples in the git repository follow the same pattern. They provide a simple RAP Application (the famous mail demo) and the files you need for the build. You can read the instructions on how to run each build in the README file which is provided for every example. For those of you who are not using git we’ve also created a zip file which contains the whole repository. You can download it here.

We plan to extend the examples in the future. A Buckminster example is on its way shortly. If you have experience with other systems please feel free to leave a comment and we can create an example together.

Tags: equinox, libra, pde build, rap, server, tycho, WAR Products

Thanks for participating in our survey “How do you run your RAP application today?“  The poll was online for one and a half months.  During this period we collected around 150 replies.

With positive replies from more than 60% of the respondents, war deployment is the most commonly used deployment scenario. Most are running on Tomcat/Jetty (39%). Every fourth installation of a RAP application is run on plain Equinox with embedded Jetty (26%).  Following quite far behind there are a few installations that are running RAP on a Virgo Web Server/Virgo Kernel and some home-brewed launch scripts.

At EclipseCon 2011, the Sovereign Project will present the latest on our ongoing research on clustering RAP in the talk, “Migrating Java Threads to Improve Availability of Web Applications“.

Currently we are targeting plain Equinox and Virgo Kernel installations. As a result of this poll, we’ll stretch our feelers to war deployment and the Virgo Web Server. It’s great to have your input for the project.

Tags: rap, sovereign, war deployment

A while ago I introduced you to my Google Summer of Code 2010 project, the WAR Products. I really appreciate your participation with feedback and bugs. It showed me that there is a real need for this tooling, so I’m proud to announce that the WAR Products development will not continue in the RAP Project.

You may think, “WTF? Odd thing to be proud of.” But, it really does make sense . The WAR Products were never targeted to be part of RAP, primarily because the tooling is not RAP specific. It eases the deployment of Server-Side Equinox applications. And this kind of application does not necessarily have to be a RAP application.

Three months ago a new Eclipse project was announced. It’s called Libra or formerly “OSGi Enterprise Tools” (it had to be renamed ‘Libra’ because of legal issues). I don’t want to repeat the project goal here because Kaloyan (the Libra project lead) does a much better job with this than I could. You can read about the project in this proposal. Libra passed the project creation review a while ago and provisioning by the eclipse.org webmasters is ongoing. So, why am I talking about Libra here?

There is a simple reason.  Because of one sentence from Kaloyan about Libra, I thought it would be the perfect project to contribute the WAR Products to.  “Libra tries to close the gap between PDE and WTP”.  This maps exactly to the WAR Products as the tooling tries to ease the deployment of Equinox-based applications on Servlet-Containers or JavaEE Application Servers.

Additionally there are plans to extend the tooling with a WTP integration to enhance the creation of a WAR Archive with automated deployment functionality, without adding explicit dependencies to WTP. And where can this development be done better than in between PDE and WTP?

Yesterday I committed the WAR Products to the Libra git repository after it passed the IP process successfully. I also set up a temporary p2 repository from which you can install the tooling (Eclipse 3.7 M4+ required). Of course we’re trying to push Libra in the direction of Indigo. If this works you will soon be able to install the WAR Products from the Indigo Repository. Please keep in mind that the bundle ID’s have changed during the move. So, if you had installed the sneak-preview from this blog post, please uninstall the tooling before installing the Libra version. It’s really worth getting the new version because of many bug fixes and enhancements which are included. Please feel free to file bugs, but this time against Libra

Please note: To use the WAR Product’s full functionality you need to add the Equinox Server-Side SDK to your target or set RAP 1.4 M5 as your target environment. There is no longer a “requiredBundles.zip” that you need. Use this temporary p2 repository to install the WAR Products: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7/

Tags: equinox, gsoc, indigo, libra, pde, rap, server-side, wtp