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

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

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

Yesterday Amazon launched a new service called AWS Elastic Beanstalk. It’s basically a Tomcat hosting service. You can upload your WAR files via a web interface, to an instance of a Linux cloud image pre-configured with Tomcat. This is from the official Amazon description:

AWS Elastic Beanstalk is an even easier way for you to quickly deploy and manage applications in the AWS cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. At the same time, with Elastic Beanstalk, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. Elastic Beanstalk leverages AWS services such as Amazon EC2, Amazon S3, Amazon Simple Notification Service, Elastic Load Balancing, and Auto-Scaling to deliver the same highly reliable, scalable, and cost-effective infrastructure that hundreds of thousands of businesses depend on today. AWS Elastic Beanstalk is easy to begin and impossible to outgrow.

So, as an Eclipse guy the first question that comes to mind is, “Does OSGi/Equinox run on this?” I mean, it definitely should because we have the great Server-Side Equinox technology which we can deploy in a WAR file. So, I did a little experiment which everyone can repeat on his own. It took only 5 minutes to confirm that Equinox can run on Amazon’s Beanstalk. Here are the steps:

1. Create a Server-Side Equinox Application and package it into a WAR file. If you want to use an existing file I recommend that you download the rapdemo.war from the RAP Examples Demo. RAP Applications are basically Server-Side Equinox Applications with a UI.
2. Create an AWS Account and activate AWS Elastic Beanstalk. Follow the steps described in the AWS Management console.
3. Use the Web Interface to upload your example war archive. Don’t forget to check “Launch a new environment running this Application”.
4. After the upload is successful you have to wait a few minutes until the instance is started. When this is finished your application will be online and reachable under name-of-your-application.beanstalk.com. The example I deployed can be reached using this URL: http://eclipserap.elasticbeanstalk.com/

It was highly likely that Equinox was going to work on the beanstalk. But to be certain it works, is even better.  I can also say that I was really impressed by how easy it is to get a WAR file running on the beanstalk.  Just  two years ago, the only option you had to deploy a WAR file was to rent a (V)Server and set up Tomcat on your own. The question for me  now is how long it will take until the deployment of OSGi bundles will be so easy. Oh wait, there is Eclipse RTP…

Tags: amazon, beanstalk, eclipse, equinox, rap, rtp, server-side, tomcat

Recently I played around a little with Tycho because we evaluated it for the use in the RTP project. As a test case, I decided to try to build a RAP application with Tycho. With building I mean compiling and packaging the artifacts into a WAR file in order to deploy them on a Tomcat or another Servlet Container.

I have to say that I’m really impressed with Tycho. Before this experience, Maven was the “bad thing that downloads the internet” to me. Okay, it still downloads the internet but in this case it’s very useful. You can add p2 repositories to resolve dependencies and it automatically downloads the right bundles. You can define the dependencies in your MANIFEST.MF and use the pom.xml to describe what kind of package it is, e.g. a feature or bundle. For building the RAP application, I just had to add the Helios p2 repository to solve all my feature’s dependencies.

Now, you might want to know how to build the application with Tycho yourself. I published the code on github [1]. It’s just the example Mail application and a sample feature that can be built with Tycho. Follow the README instructions to run the build. Here are a few notes you might need if you want to use this configuration as a template for your own build:

1. Edit the feature.xml from com.eclipsesource.maildemo.tycho.feature, adding your dependencies.
2. The build uses a static configuration.ini. As a result, you have to edit the configuration manually and add your own bundles. You will find the configuration.ini in the com.eclipsesource.maildemo.tycho.feature feature in the templates/WEB-INF/eclipse/configuration folder.
3. Create a pom.xml for every bundle you created with the following content:

   <?xml version="1.0" encoding="UTF-8"?>
   <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <modelVersion>4.0.0</modelVersion>
     <parent>
       <artifactId>maildemo</artifactId>
       <groupId>com.eclipsesource</groupId>
       <version>0.0.1-SNAPSHOT</version>
     </parent>
     <groupId>com.eclipsesource</groupId>
     <artifactId>com.eclipsesource.maildemo.tycho</artifactId>
     <version>1.0.0-SNAPSHOT</version>
     <packaging>eclipse-plugin</packaging>
   </project>

4. Change the artifactId from com.eclipsesource.maildemo.tycho to your own Id.  You’ll also need to change the parentId when you use your own Id.
5. Edit the pom.xml in the parent folder and add your modules. To add modules you just need to add the folder names from the different bundles to the file.
6. In the pom.xml of the feature, change the naming of the “maildemo” to create a .war file with the name of your choice.
7. Of course you can use your own groupIds and artifactIds. But, you have to reference the parent pom.xml artifactId in every bundle’s pom.xml

I hope these steps and the example build will help you to create your own Tycho based builds for RAP applications. Maybe you have some experiences or ideas you’d like to share?  Please feel free to post comments.

[1] https://github.com/hstaudacher/org.eclipse.rap.build.examples

Tags: build, eclipse, hudson, indigo, jenkins, rap, tycho

A few weeks ago I told you about the Eclipse RTP project. Since then some things happened that I want to share with you.

First of all, we made it to the creation review. The review is scheduled for January 12-19. The community gathering period was very successful. We reached 10 interested parties and 7 initial committers from three different companies. In this article, I’d like to focus on one very cool thing. It’s the effort made by SAP.

As you might have seen in the last months, SAP is involved in more than the half of the new Eclipse projects. Probably the main reason behind this is that SAP submitted the most project proposals . But reading about it and getting in touch with the guys behind this company are two different things as we learned in the RTP project. So, let’s review the SAP + RTP story:

In December a colleague of mine, Florian Waibel, made his way through closed airports and meters of snow to South Hampton, UK to have a face-to-face meeting with the Virgo guys. During this meeting he also talked about RTP and gained some interest from some of the people there. Back home he told me about SAP getting heavily involved in Virgo and also about their interest in RTP. Because we are an open Eclipse project we got in touch with a friendly SAP project manager (thanks Krassi) and had discussions about the RTP project and how an internal development project from SAP could fit into RTP. Well, the result was that SAP was so interested that we extended the scope of the project together and will now receive an initial contribution from SAP called the “p2 installer”. Of course, Eclipse is not a software dumping area. That’s why they will provide a maintainer for this contribution who will also be an initial committer.  Welcome Georgi Stanev .

The “p2 installer” is basically a command line interface for the official p2 installer to manage remote Eclipse runtime installations. The purpose of this tool was to enable automated scripts to install Eclipse runtime to remote systems. The cool thing about it is the ability to define the units that should be installed in a property file declaratively. Yesterday we had a short demo of the installer and I have to say that it looks very exciting.

To put it all in a nutshell it’s really good to see SAP working actively in and with the open source community. They are not shy about donating things and providing guidance. It’s very nice to see a really big player supporting open source in positive ways.

Tags: eclipse, indigo, p2, rtp, runtime, sap

Christmas is only a few days away and we at the RAP team wanted to show our appreciation to you, our community, for your active participation in setting directions for RAP and for RAP development.  As a small Christmas present, we’d like to give a preview of the next release so you don’t have to wait until June 2011 to see the Indigo features in action. Please lean back and enjoy our Indigo Sneak Preview screencast:

As you know we are an Eclipse project.  And, as an Eclipse Project, we believe in the mantra, “ship early, ship often.”   As a result of this, you don’t have to wait for Indigo to use the features shown in the screencast. You can simply download our latest milestone build or checkout the code from our CVS. You will find additional information here:

Tags: christmas, eclipse, indigo, rap

November is over now and last week I attended the last DemoCamp for the year. In this year’s November DemoCamp series I spoke at three events and with this post I’d like to present you with some impressions.

Bonn, November 16th: The beginning…

It was the first DemoCamp that was located in Bonn ever. So, as a result of this the audience was not very big, although at least 40 people found their way to the demos. I was already familiar with most of the talks.  I’d seen both Marcel Bruch’s talk on the Code Recommenders project and Mathias Sohn’s talk about EGit before, but they are still interesting. Besides these talks, one highlight was the talk about Xtext from Karsten Thoms which I hadn’t seen before in this form. He demonstrated how easy it is to create a DSL with Xtext. It’s fantastic what people can do with Eclipse technology.

Afterwards we all met at the Stammtisch. The bad thing was that Ralph Müller had to leave the talks early because he wasn’t feeling well. (Just a note here that he left before the RAP talk, so it wasn’t the talk that made him sick)

München, November 23rd: Party time…

For me it was the first time speaking at the annual DemoCamp in Munich. The organizers are well known Eclipse folks: Jonas Helming, Maximilian Koegel and Ekke. The cool thing was that these guys were so good at publicizing the camp that 100 people decided to spend an evening watching the demos. One thing that I missed was the talk by Marcel Bruch. Marcel where were you? Despite Marcel being missing, there were some really good talks. Two examples are the e4 talk by Tom Schindl and the Mylyn talk by Benjamin Muskalla. Of course both talks have been given before but I still recommend listening to them. They’re great speakers. Of course the RAP talk was another highlight

To put it all in a nutshell Munich was one of the best DemoCamps ever.  It had a very friendly atmosphere with beer service during the talks (thanks Jonas) and a great Stammtisch afterwards. But once more Ralph missed it so I had to pay for my own.

Karlsruhe, December 9th: The return of Ralph…

The last DemoCamp I visited in this series was the Karlsruhe DemoCamp last week. And guess what?  Marcel Bruch was speaking there. Why was I not surprised ? In addition to his talk, there was a world premiere in the form of Markus Tiede from Bredex presenting Jubula, one of the most recently created Eclipse projects. It was really fun to watch the IDE program by itself. Some other good talks were given by Benjamin Muskalla and Karsten Thoms. I saw Karsten in Bonn and the good thing was, that he presented two different talks. Its really nice to see that some people invest the time to provide fresh talks to the audience. I think I need to create a new talk too

The same as with the other camps, there was a Stammtisch afterwards. And surprisingly Ralph Müller was there too. So, the first round was on the Eclipse Foundation. Thanks Eclipse Foundation! I’m sure he came because he wanted to give his 6 democamps tour a nice finish. Hope to see you on more Stammtisch’s next year, Ralph.

To sum up, it was a great month with a lot of traveling. I met a lot of nice people that are all involved in Eclipse in their own way:  some as IDE users, some as contributors, some Foundation folks and a few committers – the ecosystem in its pure form. So, I hope to see some of you again at EclipseCon next year where I hope I’ll also be able to show you Eclipse RTP.

Tags: democamp, e4, eclipse, jubula, rap, redview, tycho, xtext

Today’s a great day. The Eclipse Foundation accepted the proposal for the RTP Project. RTP stands for Runtime Packaging.  And here’s what it’s all about.

Marcus Baker wrote an article called “Install Me“, which was published in the book “97 things a programmer should know“. On two pages he shows the reader exactly how important the first minutes are when a new user tries to get familiar with your software. He argues that it is the responsibility of  the software developer, to make it as easy as possible for the user to see that your software is what he needs.

Currently we don’t do a good job with this at EclipseRT. There are several EclipseRT technologies out there and every one provides an individual starting point for new users. From my point of view, changing this would bring EclipseRT a big step further.

That’s the inspiration behind the RTP project.  All that a user should have to do is download – install – run. The idea is to create one or more common starting points that new users can use to get familiar with EclipseRT technology.  Once we have the installation accomplished, we’ll have to convince the user with good examples and documentation. Investigation shouldn’t take more than 5 minutes. If the user doesn’t see what he needs in his first five minutes, the software will not get a second chance. There is also the chance of course, that the annoyed user might spread the word that the software doesn’t do the job right.  So, its definitely worthwhile to invest in keeping new users happy.

And this is what RTP is all about:  working with as many EclipseRT projects as possible to provide a really good out-of-the box experience for new users. If you are interested in this project please let me know. We welcome all help towards succeeding with RTP. If you want to learn more about RTP there are also two EclipseCon 2011 submissions (submission 1, submission 2) you can read.

Tags: BIRT, ecf, eclipse, eclipseRT, emf, epp, equinox, ercp, OSGi, p2, rap, riena, swordfish

A few weeks ago, my colleague Ralf Sternberg, announced that RAP supports a JQuery integration. What we still needed to do was to create an example that shows how to integrate some JQuery stuff into RAP. Yesterday I took a little time to work on it. I used the JQueryUI Carousel widget as a base. Two hours later the integration and a book store example were completed. You can see the result in the screencast below.

The special thing about this integration is that it uses the SWT Browser widget with BrowserFunctions. This makes this type of integration very lightweight and simple to develop. As I mentioned before, two hours were enough to create the example. Of course, besides JQuery you can integrate all kinds of Frameworks, Mashups and other things that are running in a browser. Ian Bull highlighted this by developing a GMap example. The cool thing about this technique is that it works with RAP (RWT) and RCP (SWT).

I made the source code publicly available via github. You can find the repository here. It would be great to see some other examples. So, please feel free to post your examples in a comment.

Tags: browser widget, eclipse, indigo, JQuery, rap, rcp, swt