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.

Update: I updated the code sample to use Declarative Services, as suggested by Jeff and Scott in the comments of this post. After reading this article, please refer to this other post to learn about the changes.

First of all, some preliminary steps. We need to create a new OSGi project and add some dependencies:

1. Create a new plug-in project, naming it simple.servlet. Make sure to select Equinox as the target OSGI framework on the first page of the wizard. Also make sure you've got an activator (that option is on by default).
2. Open the manifest editor and add the following packages to the Imported Packages section on the Dependencies tab:
   • javax.servlet
   • javax.servlet.http
   • org.osgi.framework
   • org.osgi.service.http
   • org.osgi.util.tracker

Next, let's create the servlet. Servlets are plain Java classes that implement the javax.servlet.Servlet interface. As we want to serve information over HTTP, we can just create a subclass of javax.servlet.http.HttpServlet which already does some of the heavy lifting for us. All we need to do is override the doGet() method. This method does not have a return value. Instead, we need to fill its second parameter, HttpServletResponse resp with the text we want the web browser to display. We could return HTML, but for simplicity's sake, let's just return plain text (so make sure to set the content type to text/plain):

package simple.servlet;
import java.io.IOException;
 
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
public class SimpleServlet extends HttpServlet {
  private static final long serialVersionUID = 1L;
 
  protected void doGet(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    resp.setContentType("text/plain");
    resp.getWriter().write("Hello from the cloud!");
  }
}

In order for the servlet to be accessible via HTTP, we need to register it. If you have done some JEE/J2EE development, you know that servlets are registered using the web.xml servlet descriptor. As we're not in the JEE world any longer, we can't go down this road. Instead, we will register the servlet using a org.osgi.util.tracker.ServiceTracker. It's a little bit more code to write, but let me tell you: it's worth it as you'll see very soon.

The service tracker will be registered for a specific class - in our case that's org.osgi.service.http.HttpService:

package simple.servlet;
 
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
import org.osgi.service.http.HttpService;
import org.osgi.util.tracker.ServiceTracker;
 
public class HttpServiceTracker extends ServiceTracker {
 
  public HttpServiceTracker(BundleContext context) {
    super(context, HttpService.class.getName(), null);
  }
  // ...

When the service tracker is asked to return the HttpService, we can register our servlet:

  // ...
  public Object addingService(ServiceReference reference) {
    HttpService httpService = (HttpService) super.addingService(reference);
    if (httpService == null)
      return null;
 
    try {
      System.out.println("Registering servlet at /simple");
      httpService.registerServlet("/simple", new SimpleServlet(), null, null);
    } catch (Exception e) {
      e.printStackTrace();
    }
 
    return httpService;
  }
  /...

Likewise, we must make sure to unregister the servlet when the service tracker is asked to shut down the HttpService

  // ..
  public void removedService(ServiceReference reference, Object service) {
    HttpService httpService = (HttpService) service;
 
    System.out.println("Unregistering /simple");
    httpService.unregister("/simple");
 
    super.removedService(reference, service);
  }
 
}

Now that we've got the servlet in place, we need to make sure the service tracker is started and stopped when our bundle is started and stopped. Those of you familiar with OSGi know where we're heading now: we need to implement the start() and stop() methods of our activator:

package simple.servlet;
 
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
 
public class Activator implements BundleActivator {
 
  private HttpServiceTracker serviceTracker;
 
  public void start(BundleContext context) throws Exception {
    serviceTracker = new HttpServiceTracker(context);
    serviceTracker.open();
  }
 
  public void stop(BundleContext context) throws Exception {
    serviceTracker.close();
    serviceTracker = null;
  }
 
}

To test your servlet locally, create a new launch config:

1. In the main menu, select Run -> Run Configurations...
2. Double click on OSGi Framework in the tree on the left hand side to create a new OSGi-based launch config

and name it Simple Servlet (OSGi)

3. Make sure you select the following eight (8) bundles on the Bundles tab:
   1. simple.servlet
   2. javax.servlet
   3. org.eclipse.equinox.http.jetty
   4. org.eclipse.equinox.http.servlet
   5. org.eclispe.osgi
   6. org.eclispe.osgi.services
   7. org.mortbay.jetty.server
   8. org.mortbay.jetty.util
4. Head over to the Arguments tab, making sure the VM arguments text box reads -Declipse.ignoreApp=true -Dosgi.noShutdown=true -Dorg.osgi.service.http.port=8080

You can now start the server by executing the launch config. After a very short time, the text Registering servlet at /simple should appear in the console window, indicating your OSGi-based server and your servlet have been started up (a lot faster that it would have taken on Tomcat or any other JEE server, for that matter).

Open your web browser at http://localhost:8080/simple to observe your servlet in action:

Congratulations, you've just built your first OSGi-enabled servlet. In the next post, I'll show you how to deploy this servlet in an Amazon EC2 instance. You can download the source code for this post from my SVN repository on Google code.

Right after my talk, Heiko showed how Xtext and Xpand can be used to generate native iPhone applications - something that he and I are currently working on as a part of our day-to-day job at itemis. Heiko's slides also are available on Slideshare.

Something which - originally - wasn't related to code generation or iPhones at all was the e4 Mars Rover Challenge. In this challenge, the goal was to control a Mars rover (built with LEGO Mindstorms) in a Mars-like environment by using an Eclipse e4 based client and a set of server components hosted on Amazon EC2. In order to win, you either needed to score the highest score or improve the Eclipse e4 client. It was left to the developer's fantasy how to improve the client. In order to score the most points, you needed to drive the rover to certain places in the Mars arena and present one of two "tools" highlighted on the rover - see the rules of the challenge.

On the first day, I played some rounds with the basic e4 client (you needed to install it on your local machine) and scored quite OK. In the evening, after I dropped off my laptop in my room, it occurred to me that without my computer, I wouldn't be able to take the challenge that evening. "Wouldn't it be awesome to use my iPhone to control the Mars Rover", I thought? Compared to a laptop, an iPhone is a very small device so you can take it with you where ever you go. Also, as the Mars Rover Challenge was setup to be a completely distributed system, with the command server being hosted "in the cloud", delivering an image of the Mars arena to the clients, I should be able to connect to the rover from anywhere on the world (as long as I have access to the internet).

When I mentioned my thinking to Heiko, he was equally thrilled as I was and we immediately set out to take the new challenge of writing an iPhone client for the Mars Rover.

We discussed quite a few interaction patterns we wanted to try out:

1. Using buttons (much like the cursor pad on a keyboard) to "joystick" the rover
2. Using a touch interface to control the rover: use pinching to rotate the rover and pointing to make it move in a certain direction
3. Using the accelerometer to be able to control the Rover by tilting the iPhone

Heiko took on the job of evaluating the human interaction interface, whereas I was busy implementing the interface between the iPhone app and the command server backend. The command server of the Mars Rover is implemented as a RESTful webservice, so I could use plain HTTP calls to send commands to the server and to retrieve telemetry and imagery data. At first, I used blocking calls and later replaced them with asynchronous calls - sometingh which I'll liekly blog about the next days, so stay tuned. In order to test my code, I implemented a very simple button-based UI. With this UI, I was able to score 2702 points - not too bad!

After just two nights of development time (we wanted to attend the sessions and also had to man the itemis booth), we finally had a slick iPhone app that was able to control the Mars Rover by using the accelerometer. In the nght just before we had to hand in our submission, we shot a video of us driving the Rover. You can watch this video on the iPhone Mars Rover website.

Here is a little diagram outlining the controls of the application:

We knew right from the start that we wouldn't be able to match the competition criteria (the contest rules clearly state that the client has to be Eclipse e4-based in order to qualify). However, we still were eager to work on this project, as it fit very well with our current obsession with all things iPhones.

While it certainly is a fun idea to use an iPhone app to control a LEGO Mindstorms robot, we would not recommend using this approach for controlling real robots - especially if they're some 55 million km away on Mars! Signal latency from Mars to Earth is said to be around 15 to 20 minutes, which suggests to use a move-oriented approach to drive the rover.

Nevertheless it has been an exciting and fun project for Heiko and me. By the way, we're not only developing iPhone apps for fun, but also for profit: we're spearheading the brand-new mobile development division of itemis, so I'm pretty sure we will blog about mobile technology soon.

People have been asking how to leverage models on and off on the web and in meetings I attended, so I thought I might share this little tutorial with you. In this tutorial, we will develop a little code generator that helps you to create (HTML) forms from models.

A short Overview

Xpand is a template engine, similar to FreeMarker, Velocity, JET and JSP. However, it features some very unique properties that makes using Xpand very well suited for generating code from models, such as type safety and polymorphic dispatch. If you haven't heard those terms before, fear not! I'll show you how to use Xpand by way of an easy-to-follow example.

The usual process of writing a code generator with Xpand is as follows:

1. Define the structure of the model you want to process. This is called a metamodel
2. Define one or more template(s) that teach the code generator how to translate your model into code.

Easy, isn't it?

Using the code generator is even easier:

1. Create a model
2. Start the code generator

It is worth mentioning that you can use Xpand to generate code for almost any known programming language. Everything you can express in text can be generated using Xpand. So, while we will be generating HTML and Java code in the following example, you can easily write code templates that generate code for C#, Basic, Lua, SmallTalk, ABAP, or any other programming language. You can also generate manuals and other documentation artifacts from your models using Xpand. I've successfully used Xpand to create DocBook files from models. Those DocBook files have then been converted to PDF files and online help files.

Preparing your IDE

1. Grab and install a recent copy of Eclipse. At the time of writing, I am using Eclipse 3.6 M6.
2. Install the latest version of Xpand (Help -> Install New Software ...)
3. Add the Xpand update site (at the time of this writing, I am using Xpand 1.0 nightly builds from http://download.eclipse.org/modeling/m2t/xpand/updates/nightly/)
4. Add the MWE update site (http://download.eclipse.org/modeling/emft/mwe/updates/nightly/)
5. Select MWE and Xpand:
   
6. After the obligatory restart, do yourself the favour and set the platform encoding to UTF-8!

Creating a Generator Project

Xpand code generators are hosted in Eclipse plug-ins, mainly because this makes handling the classpath a lot easier. People have reportedly used Maven to run Xpand code generators, but we won't go down this road today. Let's create a simple generator project:

1. Open the new project wizard and choose Xpand Project from the list
2. Choose a meaningful name for your project (e.g. org.xpand.example.gettingstarted
3. Select Create a sample EMF based Xpand project

After clicking Finish, the wizard will create an sample generator project for you:

Before we can start working with this project, we need to perform some clean-up actions:

1. Open src/metamodel/Checks.chk and delete all its contents
2. Open src/metamodel/Extensions.chk and delete all its contents
3. Open src/template/GeneratorExtensions.ext and delete all its contents
4. Delete src/Model.xmi
5. Don't forget to save all modified files

Creating the Metamodel

As mentioned before, we need to define the structure of our models before we can actually start writing the code template.
Xpand is capable of understanding a variety of metamodel types. For example, if you have an XML schema file, you can use this as a metamodel and thereby enable Xpand to use XML files which are compliant to your schema as input models. Or, if you already have a bunch of Java files making up your data model, you can use those to drive Xpand code generation. In this tutorial, however, we will be using an Ecore metamodel to define the structure of our models. The project has already been configured to support Ecore metamodels, so all we need to do is open metamodel.ecore and define the structure:

1. Please open src/metamodel/metamodel.ecore

.

2. Remove the following elements from the metamodel: Feature, Entity, Datatype, Type, Model. The metamodel should now be empty:
   
3. Select package metamodel (as depicted in the screenshot above) and add a new EClass (context menu -> New Child -> EClass). Use the properties view to change the name of the newly created EClass to Model.
4. Create a new EClass Form
5. Select the newly created EClass Form and add the following EAttributes:
   • name, set the EType to EString
   • description, EType = EString
   • title, EType = EString
6. Select EClass Model and add a new EReference, setting its attributes as follows:
   • name = forms
   • EType = Form
   • Containment = true
   • Upperbound = -1 (meaning: unlimited)
7. Create a new EClass Field and add the following EAttributes to it:
   • name, EType = EString
   • label, EType = Estring
8. Create another EClass TextField, setting its properties as follows:
   • name = TextField
   • ESuper Types = Field
9. Add one EAttribute text to Textfield:
   • name = text, EType = EString
10. Add an EClass MultiLineTextField to the metamodel:
    • name = MultiLineTextTield
    • ESuper Types = TextField
11. Now that we have everything in place, we finally need to add a reference from Form to Field so we can later add fields to a form. Select EClass Form and add an EReference to it, setting its properties as follows:
    • name = fields
    • EType = Field
    • Containment = true
    • Upperbound = -1 (meaning: unlimited)

Creating a Model

Let's now create a model that follows the structure of the metamodel:

1. In metamodel.ecore, select EClass Model
2. Create a model instance by choosing Create Dynamic Instance... from the context menu
3. Save the model file to src/Model.xmi

The model file editor will now open and you can use the tree editor to input the following model:

• Add a Form to the model, seeting the following properties:
  • Name: context
  • Description: Send your feedback
  • Title: Contact form
• Add a TextField to the Form, setting the following properties:
  • Name: name
  • Label: Name
• Add another TextField to the Form, setting the following properties:
  • Name: email
  • Label: EMail
• Add a MultiLineTextField to the Form, setting the following properties:
  • Name: message
  • Label: Message

Your model should now look like this:

Creating a Code Generator

As mentioned before, we will create a code generator for simple forms. Nothing too fancy, but enough to give you an idea of how to create generator templates.

The result will look like this:

Open src/template/Template.xpt and replace its contents with the following text:

«IMPORT metamodel»
«DEFINE main FOR Model»
«EXPAND form FOREACH forms»
«ENDDEFINE»

On the first line, we import the metamodel so that the generator (and the editor as well) knows about the structure of our model. On line 2 - 4 we define a code template named main, making sure it is bound to model elements of type Model. The template doesn't do much, except to call another template (which we will define in a minute) named form with the collection of Forms, contained in the reference forms of the current form.

Add the following lines to the template file, defining the template for the HTML file:

«DEFINE form FOR Form»
«FILE name + ".html"»



  
  

In the first line, we start the template by specifying its name (form) and the type it is bound to (Form). On the next line, we use the FILE statement to specify the file the output is going to be written to. The name of the file is derived by concatenating the attribute name of the current Form and the string literal ".html".

Continue the template by appending the following text:

«this.title»

«this.description»

Obviously, this piece of template code will create part of the body of the HTML page. Again, we will access attributes of the current Form (as read from the model) and insert their values into the template (in this case, the title and the description). By the way, you can omit the this. prefix in front of the variable names.

The template goes on with the following text:

        «EXPAND field FOREACH this.fields»

      






«ENDFILE»
«ENDDEFINE»

The EXPAND statement will invoke yet another subtemplate with the name field. This sub template will be called for each element in the fields attribute (reference) of the current Form.

You might recall that we we defined three different kinds of >Fields in the metamodel:

1. Field (which is the super class for the other two field types
2. TextField
3. MultiLineTextField

As their names imply, a TextField will be a single line text entry field, whereas MultiLineTextField will be a multiline text input field. We somehow need to be able to render different HTMNL code for each of these different text field types.

As mentioned in the introduction, Xpand is not only type safe, but also supports polymorphic dispatch. This basically means we will create three templates (one for each of the different field types) with the same name. When evaluating the code template, the Xpand generator will dispatch to the appropriate template by matching the most concrete type of the current model element.

Add the following code to the template file:

«DEFINE field FOR Field»
«ERROR "should not happen"»
«ENDDEFINE»
«DEFINE field FOR TextField»
        «this.label»:

«ENDDEFINE»
«DEFINE field FOR MultiLineTextField»
        «this.label»:
        
«ENDDEFINE»

As you can see, all three templates have the same name. Only the type they are bound to differs. This is enough to let Xpand know which template to choose according to the type of the current model element. Let's suppose Xpand is iterating the model and the current model element is a TextField. Although Field is a direct super type of TextField, Xpand will not invoke the first template («DEFINE field FOR Field»), but the second template («DEFINE field FOR TextField»), as this is the most concrete match for the type of the model element.

Running the Code Generator

If you have followed the above steps, running the code generator is a piece of cake:

Open the context menu on src/workflow/workflow.mwe and select Run As -> MWE Workflow

This will start the code generator. You will see some log messages in the console view. If all went well, the output in the console reads something like this:

...
1503 INFO  Generator          - Written 1 files to outlet [default](src-gen)
1503 INFO  WorkflowRunner     - workflow completed in 650ms!

The result of the code generation can be found in src-gen/contact.html. As this file has some dependencies to CSS/image files, please download the files from the static folder (here) and place them in your project before opening contact.html in your browser.

Where to go from here

If you want to learn more about Xpand, be sure to attend my talk Use models and let the computer do the grunt work with Xpand at EclipseCon 2010. I'll show some more advanced topics in this talk (such as generator cartridges, using Xtend to augment your models, partitioning your code templates, using other metamodels to define your models).

Xpand comes with an extensive documentation (just go to Help -> Help Contents -> Xpand Documentation in Eclipse). You can also get help on Xpand in the Eclipse Community Forums

Should you need help, itemis (the company I work with) offers training and consulting for Xpand and a host of other modeling related technologies.

No doubt you have heard about Xtext. Xpand and Xtext go together great: you can use Xtext to define the structure of your models and create great-looking text editors to edit your models. Then, use Xpand to create code generators that take your textual models and turn them into running software. Actually, Xtext comes with a wizard that you to create a code generator project for your DSL.

Downwloads

The code for this tutorial can be found in my SVN repository on Google Code.

tell application "name of your app" to launch

If you want to try this from the command line, osascript comes in handy:

osascript -e 'tell app "iTunes" to launch'

So far so good. Should be easy to do this from Java, shouldn't it? Turns out it's not so easy at all. Let's try this:

  String launchCmd = "osascript -e 'tell application \"iTunes\" to play'";
  process = Runtime.getRuntime().exec(launchCmd);
 
  BufferedReader bufferedReader = new BufferedReader(
    new InputStreamReader(process.getErrorStream()));
  while ((lsString = bufferedReader.readLine()) != null) {
    System.out.println(lsString);
  }

I'm not sure why, but it results in a nasty "0:1: syntax error: A unknown token can't go here. (-2740)" error message.

But there is another signature for Runtime.exec:

  String[] cmd = { "osascript", "-e",	"tell app \"iPhone Simulator\" to launch" };
  process = Runtime.getRuntime().exec(cmd);
 
  BufferedReader bufferedReader = new BufferedReader(
    new InputStreamReader(process.getErrorStream()));
  while ((lsString = bufferedReader.readLine()) != null) {
    System.out.println(lsString);
  }

... and this works out just fine!

Before I give some reasons why I use Twitter, let's have a look at some stats.

I sent out roughly 2660 tweets, on average 8.4 per day:

Looking at my tweet density, I hardly seem to be getting any sleep, which is not entirely true

Over the last year, I tried quite a few twitter clients, but I like Tweetie the most (yes, I'm using a Mac):

Why I use Twitter

• Twitter helps me to keep informed about topics I am interested in, while at the same time giving me the chance to get in touch with the sources of that information and give feedback.
• Many vendors and dev teams have Twitter accounts and use them to twitter about what they're currently doing / developing, again helping me to keep up-to-date about current developments
• Twitter helps me to "hear" what others are saying about the tools I and my teammates develop. Twitter clients like TweetDeck and Nambu allow you to define custom searches. E.g., I've got a search defined for "Xtext OR DSLs" so I will be informed each time someone tweets about either Xtext or DSLs. This allows me to give instant feedback to users needing help or ranting about Xtext (actually, most users praise Xtext, so I'm mostly using this search to retweet that praise)
• Twitter is like a big room in which everybody can hear what you're saying. You can use this fact to use Twitter as a marketing channel, and that's what we do with Xtext, too. We get the word out on Xtext, e.g. by announcing cool new features or talks we're giving at upcoming conferences.
• I also use Twitter to get / keep in touch with co-workers, friend and also clients. More often than not when meeting new clients, I hear people say "nice to meet you in person after we have been talking on Twitter". Sometimes, I use Twitter instead of my phone to ping people ("give me a call when you are available") - works great!
• By using Twitter, you will actually feel much closer to your peers ("tweeps") than you did before. This holds true especially for the Eclipse crowd. Many of us follow each other on Twitter and thus know what we do in our day to day job (and in our spare time, too) better than before.

Some recommendations

Whether you're new to Twitter or have been using it for years, here is my list of recommendations for Twitter. May it be inspirational for you:

• Find a decent client. The web interface is O.K., but in order to use all the power of Twitter, you need to use a real client. My main work horse is Tweetie (on the Mac), mostly because it allows me to view conversations in a really neat manner. On the iPhone I recommend TweetDeck - you can easily define additional columns to display custom searches, DMs, tweets nearby and so on. Nambu also is very nice - and native! TweetDeck on the Mac is also great, but eats a lot of resources, which is why I rarely use it any more. If you want to issue tweets without losing context, give Google Quick Search Bar a try - there's a plug-in that allows you to tweet from QSB.
• Do NOT protect your updates. After all, you want to get in touch with other people. So there really is no point in protecting your updates.
• If you're new to Twitter, make sure to post some tweets before starting to follow other people. You want to make sure other people are following you too, but why should they follow you if you've got nothing to say?
• We're not interested in disgusting details about you, your family or your friends, so keep them for you.
• I follow people mostly for professional reasons. Tweeting personal stuff is perfectly OK and can add that grain of salt which makes you human, but you should try to keep a balance.

Summing up

Summing up all things, using Twitter has helped me to get in touch with a huge amount of people I wouldn't have interacted with if I hadn't been using Twitter.

If you read all this, let me lift the secret about the obviously wrong mathematical equation in the title of this post: it's the number of characters you may use for one tweet (140), the number of days since I started using Twitter and the total number of tweets I sent out (2659). Actually, as I am using Twitter Tools for Wordpress, this blog post will automatically be announced on Twitter and thus be tweet number 2660.

The program was packed with interesting talks and we were lucky to be able to present some very well known speakers:

1. Tom Schindl: E4 - A short overview
2. Jan Köhnlein: Combining graphics and text in model editors
3. Jochen Krause: RAP
4. Nils Hartmann, Gerd Wütherich: Fifty ways to build your bundle...
5. ekke (Ekkehard Gentz):redView - dynamic views for business applications

If you were not lucky enough to attend the DemoCamp, here is a short summary of the sessions:

e4 - modeling meets runtime (Jochen Krause on behalf of Tom Schindl)

Tom Schindl couldn't attend the DemoCamp due to heavy snow in Innsbruck (the airport was short of planes to fly out, actually). After a short vcon with Tom, Jochen Krause held the e4 demo on Tom's behalf.

e4 has three principal aims:

1. simplifying the Eclipse programming model
2. enabling the platform for use on emerging web-based runtime technologies
3. and broadening participation in development of the platform

One of the measures to make programming Eclipse easier is to define a list of core services and make sure they have a really decent API. This list of services is called "The 20 Things" (see the Eclipse wiki for more information).

You might have heard that EMF is playing an important role in e4 and I think it is one of the most amazing things about e4 that the entire workbench is modeled, of course using EMF. Actually, you can change the workbench at runtime by just modifying the underlying model at runtime. I think it is very exciting to see modeling and runtime technologies converge in this project.

e4 also makes massive use of dependency injection, which allows for a flat object model (Instead of providing a subclass for every special feature, you can just inject other classes providing that particular feature). We had a discussion about dependency injection. Jochen showed that several methods in e4 use String-based dependency injection, which of course leads to several problems. Sven pointed out that this is not a DI problem per se and suggested to use interfaces to alleviate the situation.

Heiko raised the question of whether we should have a dedicated session on dependency injection at one of the next democamps:

Jochen continued his session, explaining how the e4 UI is being rendered by a presentation engine which can be configured using various renderers, each one providing an individual look and feel.

e4 is the future of Eclipse, and Jochen concluded his talk by pointing out that in order to ensure e4 has a sustainable future, companies and individuals should participate in the development of e4. This can be done by:

• Playing around with e4 and providing feedback
• Participating in the development process (see the e4 project homepage for more info)
• Paying existing committers (see Tom's blog posting to learn how to buy one and get one free)

More info on e4 can be found on the Eclipse wiki.

After the talk, we had a short break to set up the next presenter, enjoy some refreshments and, of course, socialize:

Combining graphics and text in model editors (Jan Köhnlein)

After the break, Jan Köhnlein took stage and told the audience that graphics and text and no different, but really are just two views on the same thing:

Jan pointed out that both text and graphics have their relative virtues:

Text...

• provides a detailed view on things
• can have a very formal syntax
• can be typed using standard text editors
• can be managed using standard versioning mechanisms (merge / diff)
• can be typed fast

Graphical representations on the other hand...

• provides high-level views and a good overview
• suggests non-formalism
• requires custom editors for your graphical notation (i.e., you need to write them)
• has no good support for merging / diffing
• requires the user to use a mouse a lot, and thus is slower than a text editor

Apparently, both have advantages, so why not use both?

In the following 5 minutes, Jan gave an ultra-quick introduction in how Xtext (as a representative of a textual modeling toolkit) and GMF (as a representative for a graphical modeling toolkit) work. The bottom line is both use Ecore metamodels, so we should be able to combine both.

It turns out, however, that Xtext and GMF metamodels are slightly different and you need to take some precautious steps in order to make them interoperable.

After this excursion into the theory behind the convergence of graphical and textual editors, Jan showed two editors, one graphical and one textual that synced live. Changing the model in one editor and saving it effected an immediate update in the other editor - really neat.

Jan pointed out that this is all very fine, but sometimes you really want to have a tight integration. As a proof of concept, he showed a GMF-based editor with an embedded Xtext editor: as soon as he pressed F2 to edit a field in the graphical editor, an inline Xtext editor would pop up, featuring syntax highlighting, code completion and error markers - really awesome!

More information on Xtext and GMF can be found on their respective homepages. Jan works for itemis and provides consulting and training for these technologies.

All these exciting things must have made people gasp for air, because the oxygen level in the room was very low at the end of the session, so we had another break. As always with gathering like this, hallway talks very equally important as the sessions, and people made good use of the break:

RAP (Jochen Krause)

Jochen's presented his talk on RAP without a single slide - "in the tradition of the Karlsruhe DemoCamps", as he pointed out.

No technical session without some history and some theory, so Jochen first explained that RAP implements the Half Object Pattern and demoed the very first version of RAP. While running an Eclipse UI in the browser is all very exciting, feedback from initial users wasn't too positive: "please spare us this look'n'feel in the browser!"

So the good people at innoopract (now EclipseSource) spent some time to implement custom styling for RAP UIs, which Jochen showed in his second demo, which he called "The Enterprise Look'n'Feel" due to it's feasibility for enterprise applications.

The third demo featured "rounded corners" (see RAP New & Noteworthy). While this might seem like little gained, Jochen explained that implementing rounded corners was both important on an acceptance level and challenging on the implementation level. Would you have thought that rounded corners are implemented using CSS on FireFox and VML on Internet Explorer?

Of course, RAP is implemented as an Open Source project at Eclipse, welcoming any contribution from users worldwide. Jochen demonstrated how great the Open Source model works by showing off a ribbon-style command bar for RAP which is available on Google Code (see the rapit project home page)

In the next demo, Jochen showed how he integrated EMF and RAP. His goal was to RAPify the EMF tree editor for EMF models. It turned out that basically it is very simple to convert the EMF editor (or any other Eclipse plug-in for that matter) into a RAP application - only very little adjustments were needed. However, as web applications are multi-user applications by definition, additional care has to be taken when converting editors. As Eclipse is a single-user application, editors are not prepared to be executed in a multi-user environment. Jochen explained how he tried to use CDO to store the edited models on a remote server, but failed due to the complexities of CDO. He succeeded by using CouchDB, a database written in Erlang and with an HTTP interface (look ma - no JDBC driver needed!).

Jochen concluded his session with a few notes on features they've just completed (Drag'n'Drop) or which are not available (yet) like GC.paint.

After that, he took some of the audience's questions, e.g. "How many users can a RAP server take?". Of course, it depends, but you can roughly count 1MB per user and workbench.

Jochen thought it would be OK to continue without a break, but Martin decided we should rather have a short break to let in some air.

More information on RAP can be found on the Eclipse wiki and on the project homepage. Jochen's company EclipseSource provides professional services, training and resources around RAP, so have a look at their website.

50 ways to build your bundle (Gerd Wütherich & Nils Hartmann)

After the "short" break, Gerd Wütherich and Nils Hartmann presented their view on build management: "Fifty Ways to Buid Your Bundle":

Facing the fact that nobody seems to be too excited about build management these days, they decided to arrest people's attention by adapting the well-known story "A Christmas Carol" by Charles Dickens. A brilliant idea, which really made people laugh at various points throughout the presentation.

The presentation was subdivided in three parts:

The Ghost of Build Past
Gerd and Nils explained how in the past, people have been building bundes using PDE build, using a Manifest-First-approach. Building bundles with PDE build is rather cumbersome: you have to setup map files in order to help PDE build to derive ANT build files which will then be executed by the AntRunner inside Eclipse. While this ensures the build process sees exactly what Eclipse sees when you develop your bundles in the workspace, this basically makes debugging your build process very complicated.

The Ghost of Build Today
Today, we've got bundles everywhere and OSGi is being used not only for Eclipse plug-ins, but also for conventional applications. As good programers obeying the DRY principle, we want to have a redundancy-free description of our build artifacts, i.e. derive build dependencies by looking at MANIFEST.MF. In the enterprise, things can get really nasty, as we often need to integrate various very different build systems: you might have to build an EJB client JAR (maybe using Maven) which then need to be integrated in an Eclipse RCP client application, which again needs to be built using PDE build.

Nils and Gerd showed a slide which listed all major build tools for bundles, among them:

• Springsource Tool Suite
• PDE
• Athena
• PluginBuilder
• Buckminster
• Tycho
• Maven
• b3
• Ant4Eclipse
• PDE build
• bnd
• Ivy
• Buildr
• IDEA
• Sigil
• buildr4osgi
• OsgiPlugin
• ANT
• Bundlr

After which they showed three exemplary setups how to actually build bundles:

1. ANT4Eclipse
2. Maven Tycho
3. Buckminster

Please refer to their slide deck, slides 14 - 16 for detailed diagrams on these three setups:

Ghost of Build Future
As things get more complicated, build management will also most likely become more complicated. Gerd and Nils pointed out that build management might be an unthankful job, but it must not be assigned to "people that aren't good at programming". Instead, they advocated making build management a first class citizen in computer sciences education.

More information on the tools and techniques presented are available at their respective home pages. In addition, you can contact Nils and Gerd and bug them with your questions. They're consultants, so they can be hired.

redView - dynamic views for business applications

The final session was held by Ekkehard Gentz, better known as ekke. He showed a smart combination of Eclipse technologies: Riena, EMF, openArchitectureWare (Xpand, Xtend, MWE) and Xtext. Of course, being an Open Source advocate, Ekke and his team mate Florian provide this stack as an Open Source project on Google Code.

redView is a declarative framework based on the Eclipse Modeling Framework (EMF), for creating RCP Views enriched with Riena Ridgets. It uses EMF to describe the application with a model. An Xpand-based code generator will then transform the model into code for the application. Ekke states that their goal is not to limit developers' creativity, but instead relieve them from the burden of having to write all the boilerplate code.

redView supports the most important UI elements, including some Nebula widgets. One thing I fond very impressive was their UI editor. Ekke gave a demo in which he hosted the UI model on a CDO (which seems to be Eclipse's wunderkind) server on a virtual machine. He started a second virtual machine, running an instance of the application. Upon changing the UI model in the UI designer on one machine, the UI was updated immediately on the second machine. Ekke pointed out that this usage pattern is especially useful in prototyping scenarios: the developer changes the model on his PC in his office and the customer can immediately see the changes on his machine, hundreds of kilometers away.

More information on redView can be obtained from their project homepage. Ekkehard is a freelance consultant, so you can hire him if you've got any questions regarding the technologies presented.

Gimmicks

After the demos, we raffled off 20 Eclipse Keybinding Mugs (see Kim Moir's blog post for a 360° shot of the mug) - congratulations to all winners! it-agile also provided a fine selection of agile swag: retrospective mugs, team calendars, post-its and what have you:

Despite the fact Ralph Müller couldn't attend the event, we eventually headed to the EAST bar for some frosty beverages.

All in all, it has been a very enjoyable event and from what I gathered, most attendees seem to have enjoyed the DemoCamp as well.

Thanks everyone for attending! Also, thank you to all speakers. Last but not least a big thank you to Natalia for taking pictures of the event!

Hope to see you again at the next DemoCamp in Summer 2010!

To alleviate  this situation, I decided to display the "owner" of a verb along with the name of the verb in the content assist drop down box. Here is my first try:

public class StoryDslProposalProvider extends AbstractStoryDslProposalProvider {
  @Override
  protected ICompletionProposal createCompletionProposal(EObject element, String proposal, String displayString, ContentAssistContext contentAssistContext)
  {
    if (element instanceof Verb) {
      Verb verb = (Verb) element;
      Subject owner = ((Subject)verb.eContainer());
      String myDisplayString = verb.getName() + ": " + owner.getName();
      return super.createCompletionProposal(element, proposal, myDisplayString, contentAssistContext);
    }
    return super.createCompletionProposal(element, proposal,  displayString, contentAssistContext);
  }
}

With this piece of code in place, the content assist proposals for verbs will now display the name of the "owner" to the right of the replacement text:

Sebastian pointed out that there is a getDisplayString() in AbstractContentProposalProvider that you should override in order to create a custom display string. It turned out, however, that this method will not be called as expected. I filed a bug, so expect to see a fix in one of the next milestones of the Xtext 0.8.0 stream.