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

Finally the voting process for this years Google Summer of Code is over and they announced the accepted students. I’m really happy that so many interesting proposals got trough and really looking forward to see the outcome of all the student projects.

Here is the full list of the proposals that got accepted for 2010.
Improve Eclipse Git integration
Student: Dariusz Luksza
Mentor(s): Matthias Sohn

WAR deployment for RAP/Equinox based applications
Student: Holger Staudacher
Mentor(s): Ruediger Herrmann

Theme editor for RAP
Student: Benjamin Muskalla (IRC: benny`work)
Mentor(s): Ruediger Herrmann

Rich Editor For Wiki Markup
Student: Harshana Eranga Martin
Mentor(s): David Green

index based model compare match engine
Student: Stefan Leopold
Mentor(s): Cedric Brun

Restlet integration with Equinox
Student: Rajeev Sampath
Mentor(s): Bryan Hunt

C++ editor enhancements
Student: Tomasz Wesolowski
Mentor(s): Alena Laskavaia

DNS-SD based wide-area ECF discovery provider
Student: Markus Alexander Kuppe (IRC: lemmy)
Mentor(s): Scott Lewis

Hudson Integration for Mylyn
Student: Markus Knittig
Mentor(s): Steffen Pingel

Google Wave ECF provider
Student: Sebastian Schmidt (IRC: sebs)
Mentor(s): Mustafa Isik

Integrate GMF runtime with Mylyn task focused UI
Student: Yongming Luo
Mentor(s): Mariot Chauvin

Congratulations to all the students and a big kudos to the organizers and mentors for their choice. As every year, it is pretty difficult to dismiss so many other good proposals but there were only 11 slots available this year for Eclipse. Looking forward to a great summer!

Tags: ecf, egit, emf, equinox, gmf, google summer of code, hudson, mylyn, rap, restlet, wave

I recently blogged about the OSGi EventAdmin service and got some good feedback. I like to inform people of some more things that came to light about EventAdmin. First, I added a template in PDE for the OSGi EventAdmin service that will make its debut in Eclipse 3.6 M3:

It basically uses OSGi Declarative Services to register an EventHandler that listens for the bundle started event topic by default:

org/osgi/framework/BundleEvent/STARTED

Hopefully this should make it easier for people to get started with OSGi EventAdmin.

Second, Scott Lewis from the Eclipse Communications Framework (ECF) team has a distributed version of the OSGi EventAdmin service implemented. If you want to get at the code, check out the ECF wiki.

Finally, the Eclipse e4 project (the next generation of the Eclipse platform) is somewhat interested in the OSGi EventAdmin service. There’s been discussion on a bug around the general problem of model eventing and how to avoid the ‘listener hell’ problem we had with the old platform.

Tags: e4, ecf, OSGi

In part 2 of this blog series, I described how to use Equinox p2 to install a new feature into a running Equinox application server. Rather than do this install at runtime via the OSGi console, many times it’s desirable to add bundles to an application server statically at build time rather than at runtime.  For example, this is usually the case when adding libraries for your web application to use. These libraries are sometimes created by others and sometimes created by you.

This post will go through a simple example of how to add your own bundles to your Equinox application at build time.

First, let’s return to the workspace that we setup as described in the first post in this series.  Here’s what the workspace should look like after completing steps 1-4 of the first post:

To add sets of bundles to the target application server, we create a new feature for grouping the bundles.  A feature project is created through the new project wizard via menu selections New Project->Other…->Plugin Development->Feature Project.  I’ve created a new empty feature called com.mycompany.myappserverfeature, but it can be called anything you like:

Then choose the Plug-ins (otherwise known as bundles) tab in the feature editor and you can add bundles to be included in your new feature.  The bundles that appear in the dialog when selecting Add… will include all the bundles in your workspace, as well as all bundles currently included in your target platform.  For a description of how to add to your target platform, and an explanation of what you can do with the target platform since Eclipse 3.5 please see the Improved Target Platform Management blog post.

I’ve also added some bundles in my target platform that support doing ECF remote services with the r-OSGi provider.   This enables support for remote OSGi services between application servers (i.e., having one server call a remote OSGi service exposed by another server).

After adding the bundles you wish to include, save the changes to your feature and then add your new feature to the equinox-milli.product. Features can be added to the equinox-milli.product on the Dependencies tab of the equinox-milli.product editor.

Here’s the Feature Selection dialog that appears when you select Add… on the Dependencies tab:

And then you will see your com.mycompany.myappserverfeature listed as part of the equinox-milli.product:

Save the changes to the equinox-milli.product and then you can go to product editor Overview tab, select the Eclipse Product export wizard (in lower right of Overview tab) to display the export wizard dialog:

You can now click Finish and do exactly the same things as described in steps 6, 7, 8, 9 in the original post to create a zip file (e.g., named myappserver.zip), rename it to myappserver.war and then hot deploy the new war file to your servlet container of choice to run it.

Once running, at the osgi> prompt you can convince yourself that the added bundles are now present in your application server by typing ss and looking for the bundles added by your feature in the resulting list:

As you can see, these bundles are in place and ready to use from within your web applications!

Tags: ecf, eclipse, equinox, OSGi, p2

In my previous post, I described how to easily build an Equinox-based web application server that can be run on any servlet container. Note that in the previous post I had these instructions for completing the export wizard dialog

d) The Generate metadata repository should be unchecked

If using p2 (as in this post), this is incorrect.  It should say

d) The Generate metadata repository should be checked (to include p2 metadata)

I’ve updated this documentation in the original posting.

Once your p2-enabled app server is running, you can do some really cool things with it.  For example, since p2 is available, you can dynamically install new components into your running application server.  Here’s the OSGi console help output (part of it anyway):

Notice the Provisioning Commands text.  These are console commands enabled by the presence of p2 that allow you to do common provisioning operations like installing new components.  In this blog entry, I’ll show how to install a version of the Knoplerfish httpconsole, but the same approach applies to software available from other p2 repositories.  In other posts, the EclipseSource team will show how to do this hot deployment into a running server for:

• RAP
• ECF
• Other EclipseRT Project components

First, one must add the metadata and artifact repository URIs using the provaddrepo and provaddartifactrepo commands:

Notice the provlg command, which lists the p2 groups available in the newly added repositories (in this case, the Knopplerfish httpconsole v2.0.0).  Now, issue the provinstall command with the feature group and version… wait a few seconds and you should see the install complete message

Then issue the confapply command (this command applies the new bundle configuration to the currently running platform):

Now, you can see the new bundle installed via the short status (ss) command:

To start the httpconsole bundle (and activate the servlet that it runs) just type start 50.

At this point, you can open a web browser, and point it at your Equinox application server now running the httpconsole at http://localhost:8080/myappserver/console and magic…your application server is now running the Knoplerfish httpconsole servlet, which provides a web interface to the list of running bundles:

Just for fun, you can stop the httpconsole with stop 50 and the servlet will no longer respond

You can start it back up, and then the servlet will be running again. This makes a nice demo for people that have to manage the install and update of new components into a running application server. In future posts, I’ll show how to add features to your application server statically (during the build, rather than at runtime) as well as how to use ECF remote services to manage a running application server without having to use the OSGi console.

Enjoy!

Tags: ecf, equinox, OSGi, p2, rap

Over the past year I’ve developed a goal of making it easier to build and deploy the Equinox runtime as a web application server.  Not only does this fit my technical skills having previously worked on a commercial application server, it also fits my technical interests. It also seems that an ever increasing set of other people have been interested in running the Equinox OSGi runtime as a application server. Furthermore, many people may not be aware that there are now a number of really excellent  technologies available via the EclipseRT project that are relevant to creating modern application servers:

• ECF
• RAP
• P2
• PDE
• Equinox
• EclipseLink
• Riena
• Smila
• eRCP

There’s a lot more to come, for example, ECF’s work on supporting Google Wave server protocol as well as commercial technologies from EclipseSource and other technology companies devoted to the OSGi stackless stack.

However, in my opinion it’s far more difficult to build, deploy, configure and run an Equinox server than it should be.  There is existing documentation on doing so from scratch here, but it is a little dated.  I am contributing to the Equinox project to get the documentation updated with community help.

So, I would like to do a short set of blogs about building your own Equinox-based application server.  Hopefully this will be helpful to those who are interested. It’s possible to create two ‘kinds’ of Equinox-based application servers. Those that are actually run stand-alone (i.e., as a Equinox OSGi application) or those that are run within an existing servlet container such as Jetty or most commercial application servers.  For this series, I’m going to focus on the servlet container method as I think this will ultimately be the more common and popular method. Furthermore, servlet containers now make deployment, installation and configuration very easy (which goes a long way toward my goal).

Ok, so how to create an Equinox-based application server?  Well, with the Eclipse Galileo PDE build, p2, features, and products, it turns out it’s now very easy to do so (compliments to the particularly to the folks who worked on PDE, Equinox, and P2 in this area).  I’ve created a simple feature and product that does so and contributed them to this bug.  Here are the steps:

1) Download the zip attached to bug 245267

2) In Eclipse, open a new workspace and import the projects from the downloaded zip (File->Import…->Existing Projects in Workspace->Select Archive File).  This will put two very small projects into your workspace

3) There are two other projects (from Equinox CVS area) required before you can create your app server.  To add these projects right click on the equinox-servletbridge.psf file and select Import Project Set…  from the menu (use anonymous CVS login when prompted).  Now you should have four projects in the workspace

4) Now, open the PDE product editor by double clicking on equinox-milli.product file

5) Select Eclipse product export link in lower right of product editor

6) In the export wizard dialog set the following fields

a) The Root Directory field must be set to:  WEB-INF

b) The Synchronize before exporting check box can be unchecked

c) The Destination must be set to Archive file, and given a location/name of your choosing (e.g. myappserver.zip)

d) The Generate metadata repository should be checked (to include p2 metadata)

e) Click Finish

This will run PDE build and create a zip named (in the above case): myappserver.zip

6) Now comes the fun part.  Simply rename this zip file to a .war…i.e. myappserver.war

7) Start your servlet container (in this case I’m using tomcat)

Hot deploy the war file (in this case myappserver.war) in the manner appropriate for your servlet container (in tomcat’s case this is copying the myappserver.war file into the webapps directory).  After a few seconds, you should see something like the following output to the tomcat console…with the nice little osgi> prompt, indicating your Equinox server is deployed and running!

9) Give some OSGi console commands with the osgi> prompt just to convince yourself everything is working…e.g.

10) Go show your colleagues how easy it was to create, deploy and run your Equinox application server!

There’s a lot more that you can now do with your Equinox application server like:

• Adding servlets (via bundles)
• Using P2 to update your application server
• Creating your web applications in a modular fashion using bundles and features
• Reuse your favorite bundles from Eclipse or other projects
• Deploy and maintain your web application as bundles (and using PDE to do it)

In the future, I’ll describe how to do some of these things.

If people are interested in particular things to do, please comment and let me know.

Tags: ecf, equinox, OSGi, p2, rap

There is a very cool new tutorial by Bryan Hunt for using ECF‘s implementation of the OSGi Distributed OSGi spec (RFC 119) and OSGi Declarative Services (DS) together to do remote declarative services.

In addition to demonstrating the power of combining DS with ECF 3.0′s support for distributed OSGi services, the tutorial has two other very cool aspects:

• It was created by a community member after using these technologies to build their own system
• The tutorial will soon be contributed to the ECF documentation section available in the ECF wiki area

Enjoy!

Tags: ecf, OSGi, rfc119

A few months ago I introduced you to REST. Since then my Google Summer of Code project, REST abstraction for ECF, has been accepted and a lot of work has been done. Scott Lewis and I wanted to make the use of any REST services as simple as possible and whats simpler for a bundle developer than an OSGi service?

First I want to give  you a little code snippet to see how we access a REST based web services:

IConnectContext context = 
     ConnectContextFactory.createUsernamePasswordConnectContext("user", "password");
container.setConnectContextForAuthentication(context);
remoteService = container.getRemoteService(RestService.class.getName());
try {
     remoteService.callSync(new RestRemoteCall("getUserTimeline"));
     TwitterService service = (TwitterService) remoteService.getProxy();
     IUserTimeline timeline = service.getTimeline();
     IUserStatus[] userStatuses = timeline.getUserStatuses();
     // do something with the userStatuses
} catch (ECFException e) {
// handle exception
}

What have we done? We use an ECF container to get an IRemoteService object which we use to call an IRemoteCall with the method getUserTimeline. After this we access the service’s proxy object which is an instance of TwitterService.

As you surely imagine this snippet has something to do with twitter

Twitter provides its services over a REST based API. The messages you post to twitter are stored in a timeline because every message has its unique timestamp. To access your own timeline you can use the URL: http://twitter.com/statuses/user_timeline.json. But this URL is not defined in the above code snippet. So where do we define this kind of resource? Therefore we can use our own ECF container. So let us define a TwitterContainer which extends RestContainer.

public class TwitterContainer extends RestContainer {
  public TwitterContainer(ID restId) {
  super(restId);
  Map twitterMethods = new HashMap();
    try {
      twitterMethods.put("getUserTimeline", 
        new GetRestCall(new URI("/statuses/user_timeline.json"),
        "ecf.rest.resource.json.org", 
        new Object[]{"count=2"}, null, 10000));
      registerRestService(new String[] { ITwitter.class.getName() }, 
        new TwitterService(), twitterMethods, null);
    } catch (URISyntaxException e) {
       // handle exception
    } catch (ECFException e) {
        // handle exception
    }
  }
}

As you see, we register a REST service with the timeline URL and a String called “getUserTimeline”. This String acts as a key for a specific REST service and will be associated with an IRemoteCall instance. These values are stored in a Map and registered in the container with an instance of TwitterService. TwitterService is a simple POJO which just needs to implement one interface called IRestResponseProcessor. This is needed because the parsed response has to be passed to an service object. With the parsed response, the service object can almost do everything. For example, bringing up an object model for Twitter’s timeline. If we look back to the first snippet, we see that the service is accessed via the key registered in this container. So we can register as many services we want and simply access them with a container instance at any point.

To put it all in a nutshell, we have to register our REST service as a POJO in an ECF container and just call it. This sounds almost like ordinary OSGi Services doesn’t it?

I have pre implemented two scenarios (twitter and google search) which you can check out at the project page.

I would love to hear your feedback so feel free to post comments or post on the ecf-dev mailing list.

Tags: ecf, eclipse, OSGi, rest

We’ve added to our distributed OSGi documentation (with examples+source) for ECF 3.0/Galileo:

• Distributed OSGi Services with ECF
• Getting Started with ECF’s RFC119 Implementation
• Getting Started Using the ECF Remote Services API

We have API layering so service programmers can choose the simplest appropriate mechanism for their system requirements, while still providing access to ‘lower-level’ concerns when necessary:

• failure handling
• synchronous vs. asynchronous remote method invocation
• serialization and wire protocol
• and so on…

If you have any questions or comments, please let us know on the ECF mailing list.

Tags: api, ecf, eclipse, equinox, OSGi, rfc119

As Elias and Darin already blogged, there was a memorable DemoCamp session in Portland Wednesday night.  Thanks to Instantiations for organizing and hosting.

The ECF slides for this are here.  Some of them I didn’t actually have time to show at the DemoCamp, so there’s a little new information there, even for those that were present.

Tags: ecf, eclipse, OSGi