The Eclipse DemoCamp i Copenhagen

Outside it was very cold and dark last night, but inside the IBM's building on Østerbro in Copenhagen, it was warm and nice. And we had lots of coffee and sandwiches (Thanks to the Rational Software group of IBM Danmark), so everybody was content. And after all, the presentations was all pretty good too.

[You can find links to all slides at eclipse.dk]

Android Development in Eclipse by Ronni Kahalani
First, Ronni Kahalani talked about Android development in Eclipse. He went out to buy a simple and cheap phone that could just ring, for 40$, but ended up with something else, the Android 2.2 based Samsung Galaxy 9000 S - which made the start of his Android development era and life got a hole lot more interesting.
Now Ronni wanted to create some interesting applications and he described exactly what you need to do to implement a simple application for Android.

The example was a very small, yet quite impressive, a quick SMS (SMS Now) application that could send predefined SMS's (Text message) to any contact... It was quite impressive to see the code behind the application as well as how the application was debugged... (As a side note, quite a few of the participants from the demo camp would like to participate in the upcoming Android tutorial day).

UI Bindings - a UI framework for EMF based applications by Tonny Madsen
Tonny Madsen talked about an open source Java based framework used to ease the generation of the user interface (editors, views, wizards, etc) for large applications based on EMF models. The idea is to avoid all the boilerplate code to ensure a consistent and complete UI, but yet have the full power of Java available for the UI generation. Many other resent alternatives uses large amount of XML but does not have the same flexibility.

IBM Rational Team Concert by Morten Madsen
Morten Madsen presented some of the possibilities of the free edition of Jazz and Rational Team Concert. He focused on the way a developer will see the the world when using these tools. We will definitely need a shoot-out between Jazz on one side and Mylyn and Git or Mercurial on the other side... Maybe some future arrangement... For now we will arrange a Jazz tutorial day... (and a Mylyn arrangement as well in the srping...)

Developing an IDE for testing services and mainframe applications by Steen Brahe
Steen Brahe talked about a test framework, he has developed in his job at Danske Bank.
The test framework is used for unit tests of PL/1, COBOL and web services developed in the bank. No commercial tools for PL/1 or COBOL exist and only few tools for web services can be found. Steen demonstrated the tool against the live test system of the bank and it was quite impressive.

Eclipse e4 - Status and the Future by Tonny Madsen
Tonny Madsen then returned to talk about the current status of the Eclipse e4 project as well as the status of the current Eclipse 4.2M3 release. The new release is quite snappy and holds a lot of promise to future RCP applications. Whether it means anything for the IDE is a question nobody can yet answer.

Eclipse e4 and CSS styling by Ronni Kahalani
Then Ronni Kahalani returned on stage to talk about the CSS capabilities of Eclipse e4 based applications. After a small introduction to CSS technologies, Ronni illustrated how the code works in a smal sample application.

Building with Tycho by Maksim Sorokin and Johannes Serup
Last on the agenda was Maksim Sorokin and Johannes Serup to talk about how they use Maven and Tycho in their company, 3Dfacto. They first presented Maven and how Maven is traditionally used. They then introduced Tycho and told how Tycho can be used to build Eclipse plug-ins via the Maven build system. We probably have to look into Type to see whether it can help.... 


Looking forward for EcliopseCon 2011

Now that Chris Aniszczyk and all his fellow program committee members have forced us to submit our ideas for the program of the next EclipseCon, I cannot help wonder..

Whether we will see the return of the chocolate fountain?
By Boris Bokowski

Whether the bar will be just as crowded as last year?
By Anne Jacko

What will ruin the night this time?
By Anne Jacko


Getting ready for the democamp in Copenhagen

Check list for the Eclipse democamp in Copenhagen:

Found a suitable location? Check (IBM, Lyngbyvej 2, 2100 Østerbro)
Found a sponsor for snacks and drinks? Check
Found a date? Check (Tomorrow - December 1st)
Found a number of interesting presentation? Hope so...
Set up a sign-up page? Check
Finished presentation? Almost...


Where to host and build...

I have a open source project, I would like to give a better home. Currently I use Eclipse Labs, but I do miss a number of services, so I would like to hear what other people do with similar projects.

What I like to see in the new project home is

  • Source management - Mercurial is preferred but Git could be used as well
  • Wiki pages for the documentation
  • An issue management system with a good integration with Mylyn
  • A simple way to provide continuous build based on check ins in Mercurial or Git
  • A simple way to provide a p2 repository based on the results from the builds
  • All of the above in the clouds... I don't want to host any dedicated hardware
The suite from Atlassian works be fine - I have used this in several commercial projects - but requires a dedicated host as far as I can see (until now I have managed to have all my needed services in clouds...) Bitbucket, javaforge.com and sourceforge.net are all in the clouds but all miss the good Mylyn integration and the continuous build...

I don't mind paying for hosting, but given that this is an open source project, I cannot pay a fortune every month...

So, to all the open source project maintainers out there: what do you do?

Making Slides Public

I have begun to make most of my slides public via slideshare.com.

Until now, it have just been the more relevant slides from presentations, I have held at various occasions such as EclipseCon and Eclipse Summit Europe as well as presentations from eclipse.dk and the Eclipse Banking Day in Copenhagen. You can also find some of my MDD lectures at the IT University in Copenhagen here.

I will soon also make the first part of my slides for Eclipse RCP training available via slideshare.com. It takes a little work, so stay tuned. I will try to maintain a complete list of public slides on our web.

Please note that for all the usual reasons, some of the slides and videos are in Danish :-)


ESE 2010 - Getting back to work can be hard

Another Eclipse Summit Europe is over and it is time to get back to the tasks that was postponed during the event. And it is time to reflect over what was good and bad in the event. If you participated, you should also consider doing the survey... this is the best way you can help improving the event.

I really feel I have taken a lot of interesting information back home with me. There are quite few technologies and projects in the Eclipse world - both new and not so new - I will have to look into in the time to come.

If I should point at one particular technology, I will have to look much further into, it will be XText. I have used XText professionally for the last year, but some of the things that was showcased at ESE, was well beyond anything I knew about. And I even teach about XText at the IT University in Copenhagen :-) The ability to use XText with Java types is one thing I will have to check out... especially the way the XText document was part of seaches!

Another interesting technology is OCL, especially using OCL to specify live constraints in models. A well known performance problem most have experienced is the needed re-evaluation of the constraints when the data of the model changes. How do you limit the re-evaluation to just the constraints that needs to be evaluated? For a large model, the naive re-evaluation can take seconds or even minutes.

I have just three wishes for the next Summit.

First of all, I would wish the venue could be at a different location next time. I have nothing specific against Ludwigsburg, the Nestor Hotel or Forum am Schlosspark, but after four(?) years it is just time for a change of venue.

Also I miss the symposium format we had a few years back. The Modelling Technology showcase we had this year was fine and extreemely interesting, but I also feel that it was a lot easier to get involved in the longer term chances of Eclipse with the old symposium format. I really want both at the same time :-)

The last wish is for more built-with-Eclipse stories. This is where you really see what is possible with Eclipse.. where the envelope has been pushed a little further than before...

Other than that, this was a perfect Summit, and many thanks to the organizers for all their work and impossible prioritizations.

See you all next year... wherever that may be...


Eclipse Banking Day in Copenhagen - just around the corner

In just two weeks, we will have an Eclipse Banking Day in Copenhagen. The event takes place at IBM's offices in Lyngby north of Copenhagen on June, 1. As of this moment there are 80 registered participants, so we have room for just a few more.

For those that don't know yet, here is the official description of the event:
Eclipse Banking Day is a day-long event for senior technical developers, architects and managers in the finance industry to learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. The event will focus on three themes:
  • Eclipse as a platform for application development;
  • Leveraging Eclipse modeling technology for data exchange; and
  • Collaborating with the open source community.
Attendees will have the chance to hear speakers from leading financial institutions and experts from the Eclipse community. This event builds on the success of Eclipse Banking Days in London, New York and Frankfurt.

Attendees to the event must be employees or contractors of a financial institution. There is no cost to attend but pre-registration is required.

We found many different and varied speakers - some with a banking background and some with a technical background - some of them are:
  • Mike Milinkovich, director of Eclipse Foundation, giving the keynote.
  • Martin von Haller Grønbæk, IT-attorney, who speaks about the legal issues surrounding licensing and IP rights
  • Jochen Krause, Eclipse Source, talking about RAP and how an RCP application can be presented in a web browser
  • Oliver Wolf, SOREPA, talking about SOA technologies in Eclipse
  • Patrik Tennberg, Nordea, talking about their RCP application in the bank
  • And many more
The full program is found here. There will also be ample opportunity to talk with all these people during the day.

We have room for 100 people from the financial world in the Nordic countries (Denmark, Sweden, Norway and Finland) which helps determine the development strategy of their firms. It's typically people from banks, insurance companies, pension funds, and mortgage companies with titles such as CTO, development manager, system architect and the like.

Eclipse Banking Day is sponsored by BSI AG, EclipseSpource, the Eclipse Foundation, IBM, Instantiations, Purple Scout, ReportSoft, SOPERA and the RCP Company. The support provided by these organizations has made it possible to offer this event free of charge to participants.


The importance of a clear description for bug 8009

For the nth time bug 8009 "Split File Editor" is discussed - n being rather large... This never-ending story is one of my favorite pass times when it comes to following Eclipse bugs... I really only have one wish: we need some new and fresh comments.

Well... lately, there have been some development in the comments, as already described by Holger Voormann, a bounty has now been started. In my book, the people behind the bounty now only need three things: a clear description, sufficient funds and a convinced committer. Will that happen? I think not.

In order to ask somebody to create a patch, the bounty givers/providers (?) must agree on a clear description of the problem and the wanted solution. Looking quickly through the 146 (!!) comments, I have not found a clear description of the wanted solution - actually I have found many different vague descriptions -, so one must wonder: does the current bounty givers have a common consensus for the wanted solution? If that is not the case, I can only guess that some of the people are going to be rather disappointed when they see a solution...

Most of the committers of the platform seems to agree, that the any implementation of this bug is going to be non-trivial. Thus, one must expect that the bounty for the bug must be relatively large - unless somebody goes the for the bounty just for the fame. But it is not enough to create a patch for the bug: as the patch is going to be relatively large, all sorts of committer rules are going to be in effect. Remember that somebody will have to maintain the patch afterwards. I.e. one of the existing committers for the platform must accept the provided patch as his/hers own and maintain it ever after. (Admitted, here I take it for granted that the bounty givers are not going to collect enough funds to pay for the continued maintenance of the solution... not an unreasonable assumption, I think).

I make my living by developing or help developing Eclipse RCP applications. So as a consumer of the Eclipse sources, I really, really don't want anything new in the platform unless all of the current committers can vouch for the solution. The platform has to be rock solid, otherwise we cannot base mission critical application on top of the sources. (Yes, I know that this basically means the development of the platform is almost none as the current code base is so old and complicated, but... that is exactly only of the aims of the e4 project, right?)

So... summa-sumarum: 1) you need a clear description of the problem, 2) you need funds and 3) you need to convince an existing committer that your solution is sound and good...

I can see 2) happen, I think 1) is going to be hard and 3) is going to be nearly impossible!


Dependency Injection in e4 Revised

EclipseCon is the perfect occasion when you want to discuss the way things are done in the various projects of Eclipse. Not only will almost everybody that matters in the projects be present at the conference, but there are usually also plenty of opportunities to get the right people together to discuss stuff.

In this case, I asked for a BoF on the use of Dependency Injection in e4 based on a previous blog entry on the subject titled "Dependency Injection in e4 - just why do we want to do that?". 9 people showed up and we had a pretty good discussion on the use of DI in e4 and how the usability could be improved.

The results can be found in a number of bug reports:
  • Bug 300099 - How developers are expected to discover injected values?
  • In comment 7 Paul Webster sums up the discussions quite nicely.
  • Bug 307061 - Use annotations for invoke
  • Bug 302824 - Add support to get easy access to workbench services without DI
All in all, I have to say, I fell a lot better about dependency injection now than before the BoF. With these changes, we will suddenly have most of the usual tooling in e4 as we know it in 3.x....


Preparing for big oil accidents - and how to avoid them

EclipseCon have just started and we - Frode Meling of Marintek in Norway and I - are preparing for our lightening talk "Modeling the World - If you want to move an oil rig, then model it first" that will take place Tuesday afternoon 16:45 in Lafayette.

Having just a lightening talk for the subject has turned out to be the big challenge, so we have looked at the old proverb "A picture tells a 1000 words", and found a very good video to illustrate the idea of the application in question.

You really don't want this is happen - it builds a compelling business case for the application. (I'm not saying this particular accident could have been avoided with SIMA, but...)


Using Adapters in Handlers to control functionality

In my last blog post about the use of Dependency injection in e4, I used adapters in handlers with functional interfaces to control the enablement of functionality in an application. By request, here is an extended version of that with some additional explanations. [Incidentally, this was proposed as a talk for EclipseCon ´10, but unfortunately got rejected...]

Note that this is only for users in larger applications - if you have a command with a single handler and simple expressions, then this is not needed at all...


When you implement a larger Eclipse RCP based application, you can run into a number of problems with handlers and menus as you add more and more objects to the domain model of your application model and more and more commands for the objects in the UI.

In order to control the visibility of menu items in menus - most notable the popup menu - you have the visibleWhen construct for the commands in the menu. The used expression often is an or-ed together version of all the activeWhen expressions for the handlers for the command in question. E.g. if you have a command C with two handlers h1 and h2, each with the activeWhen expression aw1 and aw2, then you often want the command to use the visibleWhen expression (or aw1 aw2).

But... as new objects can be added by new plug-ins and the number of commands are enlarged for the existing objects over time, how do you maintain the visibleWhen expression?

Also, very often, you have a lot of common implementation for a specific command in the different handlers for the command - this is not so surprising as the command is an abstract description of some functionality - e.g. "cut", "print", "connect", etc - and some common code must be expected no matter which object that is operated on. E.g. consider the "print" command: a lot of the code for selection of printer and print options will be common no matter which object is printed.

Finally, very often, you really don't want to introduce all the different UI functionality in the domain model itself - maybe for principle reasons or maybe because you don't "own" the code of the model and cannot modify it. You might therefore want to use adapters to handle the functionality in the cases where you cannot change model and direct methods where you can change the model.

For these different reasons I often use a common design pattern in my applications that incorporate functional interfaces for the different commands, adapters for the implementations and some very simple handlers on top - and not least some very easy-to-maintain menu and handler expressions.

In the following, I have used a very simple RCP application as the example with just a single view that shows a table with a number of objects. The objects are Contacts - with name and address -, Customers - extends Contact with a segment - and Segment - with just a segment. [Yes, we could have used a set of model interfaces in this example as well, as we would if we had just used EMF for the model, but in many domain models, that is just not possible...] The table have a popup menu with just a single command "Show Segment" that should be shown for all Customers and Segments, but not for the Contacts. The command must show the segment of the selected object if relevant.

The complete test application can be found here.


First, I use a functional interface for each of the domain model commands in the application. These interfaces have a number of methods used by the command handler to execute the wanted operation. Often this is just a single method, but there can be multiple methods for more complex scenarios.

In this case, the functional interface could be as follows:

public interface IDoShowSegment {
  void doShowSegment(Shell shell);

The doShowSegment method could also have been getSegmentName...

In my example, the Customer class implements the interface directly, whereas the Segment class does not, but have an adapter factory instead. The relevant part of the Command class looks as follows:

public class Customer extends Contact implements IDoShowSegment {
  // ...

  public void doShowSegment(Shell shell) {
    MessageDialog.openInformation(shell, "The customer segment is...", getSegment());

And the relevant part of the adapter factory looks as follows:

public class SegmentAdapterFactory implements IAdapterFactory {
  public Object getAdapter(Object adaptableObject, Class adapterType) {
    if (!(adaptableObject instanceof Segment)) {
      return null;
    final Segment s = (Segment) adaptableObject;
    if (adapterType == IDoShowSegment.class) {
      return new IDoShowSegment() {
        public void doShowSegment(Shell shell) {
          MessageDialog.openInformation(shell, "The segment is...", s.getSegment());
    return null;

  // ...

The factory is installed using the adapters extension point

<extension point="org.eclipse.core.runtime.adapters">
    <adapter type="com.rcpcompany.ex.adapterhandlers.functionality.IDoShowSegment" />

[The used functional interface isn't perfect, as it forces the adapter factory to construct a new object for each call to the getAdapter method. It can be helped by changing the method to doShowSegment(Object,Segment), but... for the sake of simplicity...]

To invoke the "Show Segment" functionality for a specify object, we when have to do the following:

final IDoShowSegment showSegment = (IDoShowSegment)Platform.getAdapterManager().getAdapter(element, IDoShowSegment.class);
if (showSegment != null) {
  final Shell shell = ...;

Note that we here just ignore the case where the object cannot be adapted to our functional interface.... Also note that the getAdapter method of the adapter manager automatically checks if 1) the object directly implements the interface, 2) the object implements the IAdaptable interface - and then uses this, or 3) if an adapter factory is installed for the interface and object class.

In the context of the handler, this is as follows - with the obvious declarations for the handler.

public class ShowSegmentHandler extends AbstractHandler implements IHandler {
  public Object execute(ExecutionEvent event) throws ExecutionException {
    final ISelection selection = HandlerUtil.getCurrentSelectionChecked(event);
    if (!(selection instanceof IStructuredSelection)) {
      return null;
    final IStructuredSelection ss = (IStructuredSelection) selection;
    final Object element = ss.getFirstElement();
    final IDoShowSegment showSegment = (IDoShowSegment) Platform.getAdapterManager().getAdapter(element,
    if (showSegment == null) {
      return null;
    final Shell shell = HandlerUtil.getActiveShellChecked(event);
    return null;

With the above code and a menus extension, the "Show Segment" command is shown as enabled in the popup menu for all items - even the Contact objects.

To make the handler only active when the selection is an object that supports the functional interface, use the following handlers declaration:

<extension point="org.eclipse.ui.handlers">
      <iterate ifEmpty="false" operator="and">
        <adapt type="com.rcpcompany.ex.adapterhandlers.functionality.IDoShowSegment" />

With this declaration the command is only enabled in the popup menu when relevant, though it is still shown for the Contact objects.

To show the command only when an active handler exists, use the following visibleWhen expression:

<extension point="org.eclipse.ui.menus">
  <menuContribution locationURI="popup:org.eclipse.ui.popup.any">
    <command commandId="com.rcpcompany.ex.adapterhandlers.commands.ShowSegment" style="push">
      <visibleWhen checkEnabled="false">
        <iterate ifEmpty="false" operator="and">
          <adapt type="com.rcpcompany.ex.adapterhandlers.functionality.IDoShowSegment" />

Note that this only use the activeWhen expression to control the visibility of the command in the menu. This is slightly different from the visibleWhen with checkEnabled=true, which is based on the enabledWhen expression.

The End Result

The end result is that if you want to implement the command for a new or existing object you must either extend the object with the functional interface or add an adapter for the object class to the functional interface - I usually prefer the later.

To find the objects that supports the command, just look for implementations of the interface - which by the way I normally name "IDo<command-id>" - here IDoShowSegment.

Useful? In larger applications, yes - in small applications, this is probably like shooting flies with canons. Is it worth the added code and the redirection in the handler? That can only be decided by you...


Dependency Injection in e4 - just why do we want to do that?

Lately, I have been giving a number of presentations of Eclipse e4. The focus has been on the changes that we will see when we program for e4 rather than 3.x.

With all the presentations, there have been a very lively discussion on the pros and cons of the new technologies in e4, but one subject in particular have been discussed: the use of Dependency Injection (DI) and what it will mean for productivity, testing and the tooling in Eclipse we all have grown so used to.

The following examples are taken from the excellent e4 contact manager by Kai Tödter that shows off some of the interesting features of e4 including theming and DI. The manager is very e4'ish and use the e4 features as these are probably meant to be used - with other words, I don't fault Kai for the examples or the problems I find in the examples.

At first glance the use of DI seems to give some very understandable code and it has the potential to do away with some of the listener code that we see in many places in 3.x code.

E.g. to follow the current selection in a view - here just expecting a single selected object - you would do something like the following in 3.x (forget about removing the listener again...):

public class DetailsView extends ViewPart {
  public void createPartControl(Composite parent) {
    // ...

    final ISelectionService ss = getSite().getWorkbenchWindow().getSelectionService();
    myListener.selectionChanged(null, ss.getSelection());

  protected void setSelection(Contact contact) {
    // ... do something with the selection

  private final ISelectionListener myListener = new ISelectionListener() {
    public void selectionChanged(IWorkbenchPart part, ISelection selection) {
      if (!(selection instanceof IStructuredSelection)) {

      final IStructuredSelection ss = (IStructuredSelection) selection;
      if (ss.isEmpty() || !(ss.getFirstElement() instanceof Contact)) {
      setSelection((Contact) ss.getFirstElement());

  // ...

whereas, you will just do something like this in e4:

public class DetailsView {
  public void setSelection(@Optional @Named(IServiceConstants.SELECTION) Contact contact) {
    // ... do something with the selection

  // ...

So far, so good. A lot less code compared with the 3.x version and the intension is quite clear once you know the injection is persistent, so changes in the context is automatically propagated to the view.

The main difference between the two versions lies in the way that you find and access services: in 3.x you basically have a Java method chain - here getSite().getWorkbenchWindow().getSelectionService() - where the e4 version uses a magic class or string - here @Optional @Named(IServiceConstants.SELECTION). The general Java tooling helps us access the services in 3.x, but what type of tooling will help us in e4? And how will we get warned about accidental changed in the e4 string?

A much more problematic example - as far as I am concerned - can be found in the SaveHandler of the contact manager. This handler is used to save the current contact in the details view by delegating the save functionality to the doSave method of the view (Again, I have cut away some irrelevant stuff):

public class SaveHandler {
  public void execute(IEclipseContext context, @Optional IStylingEngine engine,
      @Named(IServiceConstants.ACTIVE_SHELL) Shell shell,
      @Named(IServiceConstants.ACTIVE_PART) final MContribution contribution) throws InvocationTargetException,
      InterruptedException {
    final IEclipseContext pmContext = EclipseContextFactory.create(context, null);

    final ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);

    dialog.run(true, true, new IRunnableWithProgress() {
      public void run(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
        pmContext.set(IProgressMonitor.class.getName(), monitor);
        Object clientObject = contribution.getObject();
        ContextInjectionFactory.invoke(clientObject, "doSave", pmContext, null);
    // ...

Basically the handler creates a new context for the operation, opens a progress dialog, installs the progress monitor in the context, and then delegates to the doSave method with the new context.

The problem is found in the inner run methods: the name of the method of the view that is used to do the save operation itself is hard-coded as a string. How is this ever going to work with the Java tooling? How can we get quick assists or refactoring to work here? And how will we maintain this?

There are also some other problems with regards to testability. E.g. if a new doSave is ever created in the view, this will not provoke either a compile-time or a run-time error, but instead just execute both methods.

In the 3.x version, I would let the views that supports the doSave method implement a common Java interface - e.g. IDoSaveable and then test for this in the handler. An example of how this can be done is shown below:

The interface:

public interface IDoSaveable {
  void doSave(IProgressMonitor monitor);

The view:

public class DetailsView extends ViewPart implements IDoSaveable {
  public void createPartControl(Composite parent) {
    // ...

  public void doSave(IProgressMonitor monitor) {
    // ... do save

The handler - note that this version uses adaption, but you could use instanceof instead:

public class SaveHandler extends AbstractHandler {
  public Object execute(ExecutionEvent event) throws ExecutionException {
    final IWorkbenchPart part = HandlerUtil.getActivePartChecked(event);
    final IDoSaveable saveablePart = (IDoSaveable) Platform.getAdapterManager().getAdapter(part, IDoSaveable.class);
    if (saveablePart != null) {
      final Shell shell = HandlerUtil.getActiveShellChecked(event);
      final ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);

      dialog.run(true, true, new IRunnableWithProgress() {
        public void run(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
    return null;

Personally I see many advantages with this version:
  • It is actually more readable, as it has very little magic - aprt from the use of the adaption
  • It is easy to find all the views that supports the save operation.
  • Everything is based on the Java tooling and we have a no magic constants of any sorts
  • Refactoring works!
  • The activeWhen expression for the handler can simply test whether the activePart adapts to IDoSaveaeble.
What do you think? Is the new magic DI code worth the lost functionality in the Java tooling? Can we invent some new tooling to make up for the lost functionality? 

    Javagruppen - the Java user group in Denmark - yearly conference

    Javagruppen - the Java user group in Denmark - have had very interesting two-day conference at Hindsgavl Slot on Fyn.

    On the first day, I first talked about Eclipse e4 and what you should expect compared with the current 3.x versions. The presentation was well received and there was a very lively discussion about the pros and cons of the different changes that are made in e4. I almost didn't have the time for the look at the code... You can find the slides here.

    I then heard Heiko Seeberger talk about Scale and Lift. Scala is cool - very cool - for an old Lisp developer like me. If only I could find the time to integrate this with PDE, then it would be extremely cool. Heiko? Lift? I don't know... I'm not into web design so to me there are just too much magic involved in this...

    Then Agata Przybyszewska talked about RSpec and Cucumber for UI and functional testing. I'm not sure I understood all, but then I have never been looking into Ruby or RSpec.

    Next day, Jeppe Cramon first talked about how they have generated code from models in a number of projects using TigetMDSD. Very smart and definitely something that scales way better than JET from EMF.

    Last I heard Tommy Dejbjerg Pedersen talk about Google Android & Wave. Rather interesting - now I see a reason to get involved in Wave. And Tommy gave me not reasons to regret my

    I look forward to next year. If just it wasn't cold outside...


    Preparing for Exams...

    I have previously talked about my position as extern lecturer at the IT University in Copenhagen teaching model driven development and domain specific languages (course description and the course blog).

    Now it is pay back time... The next three days, we will have 35 student up for oral exams based on a written report around the modernization of a fictious bike shop "Noware Bike Shop".

    As part of the report, the student had to
    • construct an EMF model (mandatory)
    • a number of OCL constraints (mandatory)
    • design a (E)BNF grammar
    • create an XText editor
    • create an GMF editor
    • do a model-to-model transformation using QVT/O
    • do a model-to-text transformation using Xpand
    ... and talk about some of the theoretical properties of the MDD/DSL area - it is a university study after all. The first two assignments have been mandatory and the students then had to choose 3 additional assignments.

    Based on the turned-in reports, we have noticed a clear trend in the optional assignments they opted to solve:

    • EBNF: 13
    • Xtext: 13
    • GMF: 11
    • Xpand: 6
    • QVT: 0
    Some of these numbers are quite obvious - e.g. QVT/O is a rather difficult subject - but other numbers have surprised us a little - e.g. the number of people that opted for GMF.

    From the course evaluation, we know that many of the student have considered the Eclipse platform a little too fragile or unstable for the work. A common scenario has been that two or more student had the same installation and workspace... but yet only oner of them could get the tools to work properly.

    Will they want Eclipse and/or Modeling in their first real job? We don't know yet, but we do hope that we have showed them all how useful modeling can be in the "real world"... and that Eclipse is a good tool for the job - even it is a little fragile...