With all the hoopla around HTML 5, it would be quite a surprise if modern browsers didn't have something in store with regard to voice recognition. And sure enough, there is a W3C specification for a Speech Input API. Looking at the list of authors might give us a hint as to which browser might support this API...

Using the speech input API is rather easy. All you have to do is to add the x-webkit-speech attribute to any input tag and you're done. If you're on a speech-enabled browsers (as of this writing, only Chrome 11 supports this out of the box), you can check it out in the input field below. Just click on the microphone icon and start speaking:

So, the other day I thought, "wouldn't it be cool if I could use voice recognition to look up my contacts on the social networks I am on?". Adding voice recognition support to a website you own is rather easy, as you only have to add the x-webkit-speech attribute to the respective input fields. Enhancing foreign sites, however, turns out to be a little bit more involved. Fortunately, Chrome can augment existing websites by way of so-called Content Scripts, which are a part of the Chrome Extensions API.

Writing a Chrome Extension for speech-enabling existing text input fields on just about any website was a matter of minutes, thanks to the good documentation and some jQuery to walk the DOM. Putting on the finishing touches took me some more time, and I am proud to present you Speak to Search - a Chrome Extension that lets you talk with your browser. It works with virtually every website that uses regular HTML input fields. By making some smart assumptions, the extension will automatically submit the current form if the input field is a search field. If it is not, the focus will remain in the field and the form will not be submitted. That way, you can fill out e.g. an address form.

Here is a short video of me using Speak to Search to search for some people on Xing and LinkedIn. Please note that the extension is making sure the speech recognition engine is configured to recognize German names on Xing.

Language makes us human - this is a quote from a video I found during the research for this blog post. I don't necessarily think voice recognition and speech synthesis will make computers more human, but both technologies certainly can help to create a more immersive experience. I am looking forward to seeing a broader use of the new audio capabilities of modern browsers. Feel free to grab my code from Github and create something new and exciting!

All apps allow you to browse the program, select your favorite talks and get to know the speakers (with headshots so you recognise them in the hallways). We also have included maps of the convention center as well as Santa Clara.

For a first glimpse, watch our video:

As of today, both iPhone and Android users can download the apps from the Apple App Store respectively the Android Marketplace. Here are the links:

1. EclipseCon 2011 iPhone App
2. EclipseCon 2011 Android App

If you don't own an iPhone or Android, you can always use the HTML-only version of the conference program available at http://bit.ly/econ2011html.

The iPad and BlackBerry apps will be available soon, so stay tuned!

By the way, if you run a conference and are interested in having an app like this, get in touch with us.

Until now, web developers didn't have access to the accelerometer sensor and the gyroscope sensor. With this week's release of iOS 4.2, this has changed and we can now use DeviceMotionEvent and DeviceOrientationEvent to determine the acceleration and orientation data of the phone.

Let's first determine whether the current browser supports device orientation sensing:

if (window.DeviceMotionEvent==undefined) {
}

We can then read the sensor data by registering the respective callbacks. Here's how you read the accelerometer's data:

window.ondevicemotion = function(event) {
  ax = event.accelerationIncludingGravity.x
  ay = event.accelerationIncludingGravity.y
  az = event.accelerationIncludingGravity.z
  rotation = event.rotationRate;
  if (rotation != null) {
    arAlpha = Math.round(rotation.alpha);
    arBeta = Math.round(rotation.beta);
    arGamma = Math.round(rotation.gamma);
  }
}

The gyroscope's data can be read like this:

window.ondeviceorientation = function(event) {
  alpha = Math.round(event.alpha);
  beta = Math.round(event.beta);
  gamma = Math.round(event.gamma);
}

I've put together a little demo that uses the sensor data to color some boxes on the phone's screen. Here's a short video showing it in action:

If you want to take it for a spin, open this URL in mobile safari on your phone: http://demos.peterfriese.de/gyro/gyro.html.

(image of Gyroscope by stop that pigeon! taken from http://www.flickr.com/photos/25312309@N05/2651042796/)

We had a nice lineup of four speakers - unfortunately not all of them were able to attend due to a cold, but we were lucky enough to find one additional speaker - thanks Jan!

After a casual meet-and-greet with Fritz Kola and Pretzels, Dalibor Topic opened the official part of the evening with an overview of what's coming up in JDK7 and JDK8. Here's a list of things that sound quite interesting:

• Support for dynamically-typed languages (InvokeDynamic) (project page)
• Small language enhancements (Project Coin) (project page)
• An even newer NIO (project page)

The good news of the day of course was a press release announcing OpenJDK for Mac OSX. Nevertheless, Dalibor demoed a freshly built OpenJDK 7 BSD port on his MacBook.

After a short break, it was Ralf Sternberg's turn to give an overview of RAP and explain what Single Sourcing is. With the help of RAP, it is rather easy to bring Eclipse RCP applications to the web. Of course, you'll have to pay attention to a few things, as Ralf pointed out: usually, RCP applications are single-user apps, whereas web applications are inherently multi-user enabled. Fortunately, RAP comes with a few utilities that cater for this fact.

One thing I was delighted to learn: not only do RAP applications run on the iPad, but also do they support drawing using the SWT API, as you can see in the following video:

In the last sessions, Xtext committer Jan Köhnlein showed us some of the things coming up in Xtext 2.0. Being text-addicted, Jan refrained from using slides and used the IDE instead to deliver his talk:

Jan showed us how Xbase (no, not xBase) can be used to develop DSLs (and even GPLs) that not only describe structural features but also behavior. He also demoed Xdoc, a newly invented documentation language, and the fancy new Xtext syntax view (featuring railroad diagrams).

After the demoes, we had some time for chats and impromptu hack sessions. Given the event took place in a book store (many thanks to Lehmanns for having us!), you could also browse and buy books.

Thanks to the fact we only had about 40 attendees, there were plenty of chances for networking which people really seemed to enjoy.

I'd like to thank everybody who attended the DemoCamp or gave a demo! Follow me on twitter to be informed ahead of time for the next DemoCamp!

I think the program committee have done a great job at putting together an exciting conference program with lots of technical sessions, interactive tutorials and inspiring keynotes.

As a special treat for smart phone users, we're offering a conference schedule app for iPhone, Android and all other smart phones that come with a browser. Besides reviewing the conference schedule and getting to know the speakers you can use the apps to create your very own personal conference schedule. Usually, conference attendees will use the printed conference program to mark their favorite talks - and then leave their personalized copy of the program in their hotel room or elsewhere in the conference halls!

This will probably not happen with the smart phone app, although I can recall somebody lost their iPhone at this year's EclipseCon...

Without further ado, here's a preview of the iPhone app in action:

You can download the iPhone app from the App Store. It is available world-wide and we already have a few downloads from Singapore, Korea and India! For your convenience, here's the link to the app.

We also prepared a version for Android users. Here's how it will look like on your Android device:

Head over to the Android Marketplace and search for "eclipse summit", or use your barcode scanner:

The mobile web app will be available from the Wifi landing page at the conference venue is available via the following URL: http://bit.ly/ese_app_mobile2/.

Rumor has it even BlackBerry users will get a native app. Ekke has created a native app for BlackBerry.

Using these applications, you'll be able to put together your Eclipse Summit Europe 2010 in no time. Enjoy!

The iPhone, Android and mobile web apps have been built by a dedicated team of software engineers at itemis I have the pleasure to work with. If you want to learn how we build applications like these, attend our sessions:

• Tuesday, 14:00 - Mobile Development Symposium
• Thursday 10:30 - Models To Go: How We Built a DSL for Mobile Apps With Tools From the Eclipse

Also, be sure to drop by the new website for our mobile business: http://mobile.itemis.com and follow us on Twitter: @itemismobile.

Enjoy the your conference!

In April 2010, together with the release of iOS 4, Apple changed the terms of the iOS Developer Program License in a way which basically prohibited creating software for iOS using languages other than Objective-C, C, C++ or JavaScript:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Back then, pretty much everyone was sure this update to section 3.3.1 of the license really was just one strike in Apple's crusade against Flash. Adobe had been working on a tool called Flash Packager, which allows Flash designers to cross-compile their applications for the iPhone. While this must have been bad news for Adobe (they effectively needed to write off development costs for the entire development team working on Flash Packager), it posed a serious threat to companies whose business model relied upon creating iPhone apps using tools and languages other than Xcode and Objective-C. The future for Novell's Mono Touch, Appcelerator Titanium, PhoneGap and XMLVM/iPhone didn't look very bright.

No need to say there was quite an uproar and people came up with all sorts of creative interpretations of the terms stated in section 3.3.1 to avoid being rejected from the App Store.

Of course, if a monopolist starts endangering other, dependent companies, this soon will call the Federal Trade Commission to action. It doesn't come that much of a surprise Apple published a new, very relaxed version of the iOS Developer Program Agreement just a few days ago. The new version (which is publicly available at http://developer.apple.com/programs/terms/ios/standard/ios_standard_agreement_20100909.pdf does not limit the programming languages you may use to create applications for the iOS platform any more. In particular, section 3.3.1 now reads:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

You might think that a small paragraph in a license agreement doesn't mean that much, but I think the new section will fundamentally change the way we write software for the iPhone in the next few years. Let me explain:

The new section 3.3.1 means you may write iOS software using any language you like. Yes, ANY language - there is no if and when. This means you will not only be able to write iOS software in Objective-C (which is a great language as soon as you come to grips with it), but you will be able to use language like Java, Scala, Haskell, Ruby, etc. Some people are even dreaming of using REALBasic for iOS apps.

Vendors of tools such as Mono Touch, Titanium and PhoneGap will be glad, as their business models now have a solid foundation (well, Apple may of course change the license again but I doubt they'll ever restrict the usage of other languages again). Given the announcement on Adobe Labs, I guess we will very soon see Adobe release their highly acclaimed Flash Packager for iPhone (I don't think people will seriously use this tool to create data-driven applications, but it's probably a great tool to develop games. If you're a Flash designer / developer, that is).

For the development community at large, this is great news: freedom to choose the language that fits your needs best has always been a cornerstone of successfully creating great software. People have expressed their desire to use languages such as Haskell and Ruby to build iPhone apps. Rumor has it Apple engineers have even been working on a version of MacRuby for iPhone - there you go.

At itemis, we're very much into programming languages. We're even building our own language development toolkit to support development of programming languages - Xtext. With this toolkit, it is very easy to create your own domain specific programming languages (DSLs). In the past, we've mainly been using it to create languages for enterprise and web applications. We're also helping others to (re-)build languages such as SQL. Of course, Xtext is being used to build itself - isn't that nice? About one year ago, we started implementing a programming language tailored towards creating data-driven mobile applications for the iOS platform. We're not aiming at creating a language you can use to build arbitrary iOS applications. Instead, we're focussing on data-driven applications with a drill-down metaphor. Something you can find in many applications such as FaceBook, LinkedIn, Kayak and the like. Watch the following video to see it in action:

If you're interested in learning more about APPlause, get in touch with us by mail [heiko.behrens|peter.friese]@itemis.de, subscribe to our blogs and follow us on Twitter (@peterfriese, @HBehrens, @APPlauseDSL).

In a few years, I guess, Objective-C will be just one language among many others you can choose from if you want to build iOS applications.

But why would you want to write iOS applications in languages other than Objective-C? There are many reasons:

• Use the language you feel most comfortable with. Maybe Objective-C's square brackets look scary to you?
• Use the language you have most experience with. Maybe you're a company and have a tight schedule. Writing your application using the language your developers have the most skills in helps you to meet your deadline. In fact, a friend just recently told me they used Appcelerator "because we've got JavaScript and HTML knowledge in-house, but none of our developers had experience with Objective-C"!
• use the language you use for developing your backend system. So you've got this huge backend system written C#, running on the .NT platform. Why not write all the front-end code in C# as well?
• Maybe you're a start-up in the social media realm and your website is written all in Ruby and Ruby on Rails. So why not write the iPhone app in Ruby as well?

It all boils down to being more productive and ensuring better sustainability. Using the right tool for the job helps you to achieve a faster time to market. If you're able to use the same language on the frontend and the backend, this will help you to secure your investment in this technology.

Please note that I'm not saying you should by all means write your frontend and your backend using the same technology and language. The first and foremost question you need to answer is, "what's the right tool for this job". Being able to make a real choice will help you to give a better answer to this question.

Looking back on my experience with the various drawbacks and benefits of each of those development modes, I hereby recommend your next app be open sourced.
Here is why:

Reasons pro Open Source

We all heard it before, "Open Source will make the world a better place" - but why? Well, let me give you a few reasons:

First, by open sourcing your code, your code will become better. If everybody can see what your code looks like, you will do your best to make sure it's clean code. Jeff LaMarche calls this "coding as if everybody is watching". Clean code has less errors than quick-and-dirty code, so that's a good thing.

Enabling others to contribute will further improve your code. Should you decide to invite other developers to your project, you'll want to add some documentation to make it easier for them to get a jump start. Writing documentation will force you to think through your code and its overall structure. You might find you want to perform some refactorings before you actually let other developers work on your code. This will improve the quality of your code even more.

Enabling others to participate will make your app more attractive. Didn't you experience this before: the app you just downloaded is almost perfect - if it only had this one missing feature. For example, I really love TweetDeck for iPhone, but I'm dearly missing an Instapaper integration. If TweetDeck was open source, I would've added Instapaper integration to the code and submitted a patch to the creators of TweetDeck for the benefit of the entire user base. But unfortunately, TweetDeck is not open source - what a pity.

By building a team of skilled people, you'll be able to deliver more features in a shorter amount of time than you can ever hope to achieve if you work alone. Successful open source projects are made up of a bunch of gifted individuals with diverse skills. This is even more important for mobile applications, as you not only have to develop the code that makes your app work. You also have to create a great looking UI, so might need a great designer. If you want to promote your app on a website, you might also consider teaming up with a web designer.

Speaking of contributions, you might be a bit hesitant to let other people work on your code. That's alright. Usually, contributors do not get commit rights right away. Instead, you ask them to contribute to the project by submitting patches via your bug tracker (you do use a bug tracker, don't you?). This enables you to review their code before actually committing it to the code base. If you're not satisfied, let them know (in a friendly way) what you would like them to improve. If a contributor delivers a number of great patches in a row, you can consider to promote him/her to be a committer.

Reasons against Open Source

There are a few reasons why your next app maybe should not be open sourced:

Others might steal your ideas! I keep hearing this argument over and over again. Yes, if you open source your app, other developers might check out the code, re-brand it and sell it on the app store as their invention. Well, they can steal your ideas anyway - just by looking at your app and building an app that looks and feels the same. Granted, re-writing an app consumes considerably more time than re-branding an existing code base. But I doubt anybody dares to submit a blatant 1:1 copy of an app to the app store. At the very least, you should choose a suitable license for your code. There are a number of great open source licenses you might consider check out the Rob Rhyne even had his brother (who is a lawyer) create a new app-store compatible license for his app, Briefs. Read his blog post "Selling Open Source" for the rationale behind this step.

Even if other people don't copy your entire app, they still might copy some cool UI tricks you do. Maybe you've gone to great lengths to create some really cool frameworks that make your life easier or make your app behave in a very cool and new way. You might not want other apps to look as cool as your app does. Well, it's your right. In my opinion, the app store contains way too many badly designed apps. You would do the world a favour by releasing your great library to the public. Really.

And finally, you might not be able to open source your next app because your client or the company you're working for is against open source. Maybe they have good reasons for it, maybe they just don't know enough about open source. If the latter is the case, let them read this blog post or drop me a line - I'm available for consulting.

Business Models for Open Source Apps

You might have a different point of view (and if you do, please leave a comment - I'm eager to hear your thoughts), but in my opinion open source is not a threat but a chance for your app. If we take this for granted, the question remains, how can you make money with an open sourced app? Here are some suggestions:

Sell it on the App Store. Yes, this might sound a little strange after all my raving about open source. If something is open source, how can you sell it? Well, it turns out selling apps on the App Store is a great idea, especially for open source apps. The app store is the only way how your clients can get hold of your application. Of course - they might check out your code, compile it and upload it to their iPhone. But to do so, they'd need to be registered iPhone developers, meaning they'd need to buy an iPhone developer certificate. Don't you think it is cheaper to just buy your app than shelling out 99 USD for the developer certificate?

If you're developing a library or framework, you might consider getting funding on Kickstarter. Kickstarter is a great way to get funding for your project: you define the deliverable and how much funds you want to raise and people can back your project by pledging a variable amount of money. This way, John Wain of Glyphish fame managed to raise more than 27.000 USD for developing an iPhone 4 compatible version of his great Glyphish icon set. His original goal was to raise 2.000 USD, by the way.

I hope I could encourage you to try open source as a strategy for your next application or framework. If I did, let me know! Chances are I might want to submit a patch to add that tiny little feature I think your app is lacking

Here's the detailed program:

• 18:00 - 18:40 Welcome / Short films
• 18:45 - 19:15 Lars Vogel, Developing with e4
• 19:20 - 19:50 Sebastian Zarnekow, Xtext - A Language Development Framework, Live demo of new and noteworthy features in Xtext
• 19:50 - 20:20 Break + Surprise
• 20:20 - 20:35 Jürgen Becker, UI with style - a new SWT platform that is based on Qt
• 20:40 - 21:10 Ralf Ebert, Introduction to distributed version control with Git
• 21:15 - 21:45 Heiko Behrens, Build your own iPhone app within minutes - thanks to Eclipse
• 21:45 - open end Closing remarks / Frosty beverages

The DemoCamp will take place in the MAGAZIN Cinema in Hamburg (directions) and yes, we will show some short films at the beginning of the camp for your entertainment.

Martin Lippert and I are happy to be able to present a great lineup of speakers and demos, so do yourself a favor and join us this Friday from 18:00 (6pm).

As always, the event if free of charge thanks to the generous support of it-agile, itemis and the Eclipse Foundation.

Looking forward to seeing you on Friday!

In a recent post, I showed you how to create a plain servlet and register it in an OSGi environment. As both Jeff and Scott pointed out, my using a ServiceTracker to register and unregister the servlet is a little bit clumsy and can be improved by using Declarative Services.

I highly recommend reading chapter 15 in "OSGi and Equinox", but in a nutshell Declarative Services allow you to define components which can provide and consume services. Binding and unbinding references between components and services is performed by the DS runtime (also known as the Service Component Runtime).

Without further ado, here are the changes I had to make to DS-ify my simple servlet:

1. Remove the activator. Yes, that's true: we don't need an Activator any more. Delete the class and also remove it from META-INF/MANIFEST.MF
2. Delete HttpServiceTracker. Registering the servlet with the HTTPService will be handled by the DS runtime.
3. Implement a component to register and unregister the servlet with the HttpService:

   public class SimpleComponent {
     private static final String SERVLET_ALIAS = "/hellods";
     private HttpService httpService;
    
     public void setHttpService(HttpService httpService) {
       this.httpService = httpService;
     }
    
     protected void startup() {
       try {
         System.out.println("Staring up sevlet at " + SERVLET_ALIAS);
         SimpleServlet servlet = new SimpleServlet();
         httpService.registerServlet(SERVLET_ALIAS, servlet, null, null);
       } catch (ServletException e) {
         e.printStackTrace();
       } catch (NamespaceException e) {
         e.printStackTrace();
       }
     }
    
     protected void shutdown() {
       httpService.unregister(SERVLET_ALIAS);
     }
   }

   As you can see, the HttpService will be injected into this component using it's setter method, setHttpService.

4. Register this component with the DS runtime by adding a component description:

   <?xml version="1.0" encoding="UTF-8"?>
   <scr:component
     xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
     activate="startup"
     deactivate="shutdown"
     name="simple.ds.component">
     <implementation
       class="simple.ds.servlet.SimpleComponent"/>
     <reference
       bind="setHttpService"
       interface="org.osgi.service.http.HttpService"/>
   </scr:component>

   I saved this file in OSGI-INF/component.xml and added it to the Service-Component section of META-INF/MANIFEST.MF. In fact, as I used the Create New OSGi Component wizard, the wizard added the entry to the ServiceComponent section - it's really easy to forget this if you do it manually!

That's it!

Please note that I did not change the servlet implementation at all (apart form issuing a different text to make it easier to tell the servlets apart)!

Before launching, please make sure to add org.eclipse.equinox.ds and org.eclipse.equinox.util to your launch config to enable Declarative Services.

The biggest advantage of this approach is that you do not have to take care of acquiring the HTTPService. The DS runtime will only activate your component when all prerequisites have been met, i.e., all dependencies are available. If the HttpService is not available for any reason, your component will not be started. This makes the code for registering the servlet simpler and cleaner.

You can download the source for the DS-ified servlet from my SVN repository on Google Code.

We will first set up an Amazon EC2 instance and then export the servlet and install it in this instance.

Setting up an Amazon EC2 instance

Scott Lewis was kind enough to prepare an Amazon EC2 Machine Image (AMI) that already contains Jetty, Equinox and p2 - everything we need to get our servlet running. So let's use this AMI to provision our instance:

1. Sign in to the AWS web console
2. Click on Launch instance to create a new instance
3. In the Request Instances Wizard, jump over to the Community AMIs tab
4. Type OSGi in the search field to search for ami-69d93600
5. Select the AMI
6. In the next step, you get to configure the instance. A small instance will do for now.
7. Leave the Advanced Instance options as-is
8. Next, you need to create a key pair (this will allow you to sign in to the instance using SSH). If you haven't created an EC2 instance before, select Create a new Key Pair and follow the instructions. Otherwise, select an existing key pair
9. To access the instance from outside using HTTP and SSH, you need to create and assign a security group. Make sure to add SSH and HTTP port configurations to this security group. Unfortunately, it is not possible to freely choose the port ranges, so we need to edit the security group after we're finished with the wizard.
10. On the summary page, review the configuration and click on Launch to actually start your instance.

After a little while, the newly created instance will show up in the list of AMIs. You can test your instance by opening a terminal window and SSH'ing to your instance:

  ssh -i path/to/your/privatekey.pem root@ec2-xxx-xx-xx-xx.compute-1.amazonaws.com

You should be greeted with a prompt like this:

        __|  __|_  )  Fedora 8
        _|  (     /    32-bit
       ___|\___|___|
 
Welcome to an EC2 Public Image
                      :- )
   Base

Start the EclipseRT server as follows:

cd /env/osgi_eclipsert36_sb_p2_jetty_7_0_1_linux_x86/jetty-distribution-7.0.1.v20091125/
./eclipsert36.sh

Your Eclipse RT Equinox server is now up and running. Time to export the servlet!

Exporting the servlet

We will export our simple servlet using a feature based update site, so it can be installed using p2.

First, create a new feature project, naming it simple.servlet.feature. Provide the following details to the wizard:

1. ID: simple.servlet.feature
2. Version: 1.0.0.qualifier
3. Name: Simple Servlet Feature
4. Provider: Your name

Open the Plug-ins page and add simple.servlet to the list of packages plug-ins.

Now, we can create the update site. It will only contain the feature we just created. Using the New Update Site wizard, create a new update site project, naming it simple.servlet.updatesite. Add the feature we just created to the list of features on the first page of the site.xml Update Site Map.

When you're done with that, , you can build the update site by pressing the Build All button. This will build the servlet plug-in, the feature and finally the update site. After that, we're ready to deploy.

Installing the servlet

Installing the servlet into our Amazon EC2 instance is quite easy, as we can leverage p2:

Using your favourite SFTP client, copy the entire update into the /tmp directory of your Amazon EC2 instance. When that's done, hop over to your terminal window that's connected to the OSGi console of your Eclipse RT server (remember, we started this server when setting up the Amazon EC2 instance). Issue the following commands:

provaddrepo file:/tmp/simple.servlet.updatesite
provliu
provinstall simple.servlet  1.0.0.201004091446
confapply

Make sure you use the correct version identifier, it is likely to be different from the one I used here!

You can now list the installed bundles by invoking ss:

ss
...
38      ACTIVE      org.eclipse.equinox.preferences_3.3.0.v20100208
39      ACTIVE      org.eclipse.equinox.registry_3.5.0.v20100301
40      ACTIVE      org.eclipse.equinox.security_1.0.200.v20100301
41      ACTIVE      org.eclipse.equinox.server.examples.hello_1.0.0.201003111015
42      ACTIVE      org.eclipse.equinox.simpleconfigurator.manipulator_2.0.0.v20100304
43      ACTIVE      org.eclipse.equinox.util_1.0.100.v20090520-1800
44      RESOLVED    org.eclipse.osgi.services_3.2.100.v20100108
45      RESOLVED    org.sat4j.core_2.2.0.v20100225
46      RESOLVED    org.sat4j.pb_2.2.0.v20100225
47      RESOLVED    simple.servlet_1.0.0.201004081743

Start the servlet by typing start 47 (again, please use the bundle ID issued by ss).

Open a webbrowser and navigate to ec2-xxx-xx-xx-xx.compute-1.amazonaws.com:8080/simple (the DNS address is the same you used to SSH to your instance) and you should see the servlet output:

Hello from the cloud!

Conclusion

In this post, you saw how easy it is to create an Amazon EC2 instance and deploy an OSGi-based servlet on it. With this knowledge, you can now start sky-diving into the joys of cloud computing. Have fun!

Most of this information has been taken from the Eclipse Wiki. You are encouraged to add your own tips & tricks to this wiki page. All you need is an Eclipse Bugzilla account. Setting one up is easy, start here.