This is the second part of the tutorial presented at EclipseCon. We’ll be building on the model created in the first part of the tutorial, which you can find  here.   We’ll give you an overview of available technologies through links to several Ignite talks that introduced various frameworks building on EMF.  If you would like to have your framework included, please let me know.

4 EMF API

In this part of the tutorial, we will explore EMF’s API, including the generated code, as well as EMF’s utility classes. Let’s have a look at the generated code first. In the model plugin from our tutorial org.eclipse.example.bowling you will find interfaces and implementations for all entities of the model. A look at the outline of an entity’s interface reveals that it contains getters and setters for the attributes we have defined in the model, as well as access to the references. All entities of the generated EMF model are sub-classes of EObject. EObject contains basic functionality – for example, a change notification mechanism. The model plugin contains factories to create model element entities. Please note that the constructor of EObjects is usually not public. Please also note, that factories are used by many frameworks for their functionality, e.g.  deserialization.  Changing these methods successfully requires some careful planning. Let’s use the factories to programmatically create some entities and use their API to modify them. We will use the pre-generated test plugin to run this example code. In this very simple example, we use the BowlingFactory to create a Matchup and a Game, adding a reference to the Matchup and checking the bi-directional update on the Game. The super class EObjects offers many methods to access an entity in a more generic way. As an example, we will test the containment between Matchup and Game by accessing the EContainer instead of the getMatchup() method. EObjects offer reflective access to their attributes using the methods eSet() and eGet(). This can be useful in modifying an entity in a generic way. Information about the available EAttributes and EReferences, as well as all additional concepts we have modeled before, can be accessed either through the EClass or through the EPackage. The following test checks whether the only EReference of League is a multiplicity greater than one. EMF also supports the validation of  model instances. As an example, we can validate the constraint of the model that a matchup must always consist of two games: Finally EMF provides a lot of utility classes. A very important one is EcoreUtil. It is worthwhile browsing through the available methods of EcoreUtil. As an example, we will use the copy method to create a copy of an EObject.

5 Import Sample Solution

Before we continue with the tutorial, please import the sample solution. Please switch to an empty workspace (File => Switch Workspace), select “Import” => ”General” => ”Existing Projects into Workspace”. Please select “exampleSolution.zip” and import all projects.

6 AdapterFactories

For the next steps of the tutorial it is important to understand the concept of AdapterFactories. We will give a quick introduction and you can see this documentation for more information. The basic idea of AdapterFactories is to provide you with an interface IX you need for an arbitrary purpose, e.g. a LabelProvider needed in the UI. EMF generates a lot of these classes for you. To retrieve the right class you can use an AdapterFactoryX, which implements the interface you need. The AdapterFactoryX will retrieve the generated classes using an AdapterFactory.

7 EMF Data-Management

In the previous sections we have shown how to generate a structured data model with EMF. In a typical application, these data models have to be stored and maybe even versioned or distributed. There are a couple of frameworks that support different use cases. By default EMF provides the ability to serialize EObjects to XMI files. In the following example, we will load EObjects from a file and save them afterwards. EMF also offers commands to make modifications on the model. Commands can be easily undone. In the example we will load a XMI file containing a Tournament. The user can add new Matchups to that Tournament and undo these changes. At the end, the user can save the changes back to the file. For the tutorial, we have prepared an example dialog in the plugin org.eclipse.example.bowling.tutorial, which should be imported from the example solution. You can open this dialog by right-clicking a file and selecting “Tutorial”=>”Open Example Dialog”. After implementing the following two parts of the tutorial, it will look like this: Everything that is not relevant for this tutorial is implemented in an abstract base class called AbstractExampleDialog. In the subclass ExampleDialog, there are empty method stubs to be implemented in this tutorial. The dialog can be shown in the runtime Eclipse instance by right-clicking on a file and selecting “Open Tournament Example view”. (Please note that for the tutorial we have focused on simplicity over perfect design.)

Please open the class ExampleDialog. We will implement the loadContent method, which is triggered by opening the example view. The purpose of this method is to get a Tournament from the file which is then displayed in the example view.  To keep it simple, we assume that the file contains a Tournament and this Tournament is the first element in the file. You can easily create a file like this with the generated example editor. First we create an editing domain. An editing domain manages a set of interrelated models and the commands that are run to modify them. For example, it contains the stack of all former commands. An editing domain can create a resource, which is a container for storing EObjects. Resources can be saved and loaded and contents can be added to them. In the example we get the first EObject in the resource, assume it is a tournament and make it a member of our superclass. After loading the content, we will implement a save. This will be triggered by pressing OK in the dialog and will serialize the model and apply all changes to the file. Now we want to implement the addition of a matchup to a tournament. We will use a command for this. First we create a matchup using the appropriate factory. The factory, by convention has the name of the base package of the model. Then we create a command which adds the newly created matchup to the existing tournament that we retrieve from our superclass. Finally, we run the command on the command stack of the editing domain. At this point, the changes will not be reflected in the UI of the dialog, but we will implement the necessary code in the next step of the tutorial. To implement undo, we just need to call undo on the command stack of the editing domain, this will undo the last command. Now, start the bowling application and create a XMI file with the example editor. It should contain a Tournament and several Matchups and Games. Please right-click the file and select “Tutorial” => ”Open Example Tournament View”. In this view you can add new Tournaments, undo this operation and save by clicking on “OK”. You can validate the result by opening the file in the Ecore editor. Please note again, that the UI of the View will not be updated yet, but we will initialize the UI also in the next step of the tutorial.

Additional Information

EMFStore – A Model Repository (Server for EMF Model instances)

CDO (coming soon)

8 EMF UI

In this step we will fill the example view with two basic UI elements. First, we will bind the Label on top showing the number of Matchups in the opened Tournament to the model. We will use the notification mechanism to update the Label whenever the number of Matchups changes. Second we will fill the TreeViewer with a list of the Matchups also displaying their Games as children. For updating the Label we will register a listener on the Tournament EObject, which is opened in the view. This listener will always be notified by the EMF runtime if there is a change in the Tournament EObject. In the second step we implement the listener itself. In the notify method, we check first whether the change was on the EReference to Matchups and therefore influences the number of Matchups. If this is the case, we update the Label (implemented in the AbstractExampleView). Please note that this is how you manually implement listeners. For creating UIs with bi-directional updates between UI elements and data-models, we recommend using data-binding that’s also available for EMF. In Eclipse databinding, you can bind a certain UI element to a certain EAttribute or EReference and it will take care of bi-directional updates.

Finally, we will initialize the TreeViewer to display the Matchups of the current Tournament and their Games as children. A TreeViewer needs three things to be initialized. The ContentProvider is responsible for the structure of the Tree by providing the method getChildren(). The LabelProvider is called to get an Icon and the displayed text for one node. The input of a TreeViewer is the invisible root element of the Tree. The elements displayed in the root of the tree are the children of that element. In our case, the input is the Tournament.

ContentProvider and especially LabelProvider usually depend on a certain EClass. EMF generates providers for several purposes including Content- and LabelProvider. We will use the AdapterFactory concept explained previously to retrieve the right provider for every element. Finally we set the Input to the Tournament which is currently open.

Now you’ll need to re-start the bowling example application to test the implemented UI features. To modify the appearance of a Label you can simply modify the ItemProvider of the respective class. Let’s modify the LabelProvider for Matchup. To modify the appearance of EObjects in the TreeViewer you can adapt the generated ItemProvider GameItemProvider. In the example, we will show the number of Games contained in a Matchup Game. Mark the method as “generated NOT” to prevent it from being overridden during the next generation.

In the running application, the new LabelProvider is displayed in the Example view as well as in the Ecore Editor:

As a last step, you should remove all listeners when closing the view. Please note that LabelProvider and ContentProvider are registered listeners on the model, so you should delete them.

Additional UI Frameworks

There are several frameworks for displaying data from an EMF model instance. In this tutorial, the following were introduced in Ignite talks:

• Extended Editing Framework
• EMF Client Platform
• Graphical Modeling Framework

9 Additional EMF-based Technologies

In this last part of the tutorial we want to give you a short overview of additional EMF-based technologies for different purposes:

• EMF Compare: Ignite Talk (coming soon)
• EMF Query: Ignite Talk
• EDAPT: Ignite Talk
• XText: Website

I hope you found the tutorial helpful. In case you have any feedback or you are missing a certain framework or part, please feel free to contact me or leave a comment.

Tags: emf, modeling, munich

My highlights on the EclipseCon today were the EMF GWT presentation by Ed Merks, the p2 talk by Ian Bull and Pascal Rapicault and the keynote on Watson by David Gondek:

Ed Merks showed how to use EMF with the Google Web Toolkit. In about a click or two, he had an EMF-based GWT application (or an GWT-based EMF application) up and running. The famous library model application was not only available locally on his demo laptop but also hosted on Google Appspot. It is still available here. Unfortunately Ed did not refresh his running browser instance during the tutorial, although many model updates had been waiting on the server…;)

Ian Bull and Pascal Rapicault presented a bunch of donts concerning p2 in a very entertaining way. I hereby promise, I will no longer unzip features and plugins directly into an Eclipse instance, I will never release with the same version twice or try to edit the p2 metadata . Also throwing in 1000+ plugins into the dropin folder seems to be a discouraged practice, at least if you would like to have a speedy Eclipse startup. Seriously, this was a very informative presentation and it showed how to avoid “trouble” with p2, which is in many cases trouble that we caused ourselves.

In his keynote David Gondek explained the mission of Watson and how it works. Today keyword search is widely used, but it comes with the disadvantage of putting the burden of selecting “good” keywords on the user. In general adding more keywords to a search will decrease the quality of the results. Among many interesting statistics, I found the statistics on the top 10 “What is …?” searches in Google particularly interesting. On the first place is the question “What is love?”. Consequently the question “What is autism?” is on the 7th place . In contrast to keyword search, Watson uses a comprehensive analysis and reasoning to answer natural language questions. For example Watson has a geographic reasoner which can relate words in terms of the geographic distance. Thereby Watson can even find answers to tricky questions in Jeopardy. The many examples in the keynote provided a lively picture of the problems building the next generation search engine.

Tags: eclipsecon, emf, modeling, p2

This is my first blog post under the EclipseSource roof. Thanks for all the greetings and congrats!

I shortly want to summarize my impressions from the EclipseCon yesterday (Monday):

Tutorial: What every developer needs to know about EMF. Since I was one of the authors I am not going to comment on the quality of the tutorial . About 80 people joint the tutorial and the number of participants did not decrease during the 3h tutorial. That should be a good sign. Jonas has blogged the contents of the tutorial here so no need to go into detail.

Efficient, Scalable Notification Handling for EMF. Listening to the changes of huge object graphs in EMF can be tricky, especially if you add adapters to many objects by many different listeners, which only trigger under certain conditions. Currently in EMF you can only register an adapter in general and you cannot specify conditions when the adapter should be notified. This can be a performance issue. The talk showed an event manager for EMF notifications which allows to register listeners including conditions when to notify the listeners. It is really cool that this component exists now, we have already partially developed custom solutions for this problem, now we can use this sophisticated implementation.

Tired of CVS? The talk presented how a streamlined work flow with Git, Gerrit, Mylyn and Hudson could look like. In the work flow a developer uses Mylyn to track requirements and tasks, EGit automatically manages change sets and committing to EGit automatically creates a code review in Gerrit and triggers a Hudson build. Looks like a beautiful new world to me!

Workshop: Tycho Build Conversion I tried to get the EMFStore build running with Tycho and Maven and it worked out pretty good. I did not get the build completed, but I had to leave after 1h. Overall I had the impression that building with Tycho could really be an option and I will definitely go and investigate this further. A good cheat sheet for converting an existing build to Tycho is available here.

Finally I went to the committer reception…meeting people and drinking beer .

Tags: eclipsecon, emf

So this is my first post at the new location. As Jochen announced earlier, Maximilian and me are joining EclipseSource in Munich. We are very happy about this and look forward to the collaboration.

Today, we have presented the Tutorial “What every Eclipse Developer should know about EMF” at EclipseCon. I will blog the tutorial here step by step. You can download a PDF version of this tutorial here.

So let`s get started

Abstract

You did not use EMF before? What is EMF anyway? What is all this modeling stuff about? And who is this Ed guy?

This tutorial introduces the use of EMF and explains the basics. We show how to build a very simple data-centric application based on EMF including the UI. We explain how to define a model in EMF and how to generate code from it. We explore the API of the generated code to create, navigate and modify model instances. We demonstrate how to build an UI based on this model. As an example we build an application to manage a bowling league and tournaments.

In the first step of the tutorial we will create the underlying model of our example application.

To follow this tutorial, please use a (fresh) instance of the Eclipse Modeling Tools Helios for your OS.

Later in the tutorial, we will use this example solution: exampleSolution

Authors:

• Jonas Helming (Basic Tutorial, EMF CP Ignite), jhelming@eclipsesource.com
• Maximilian Koegel (Basic Tutorial, EMFStore Ignite), mkoegel@eclipsesource.com
• Markus Herrmannsdoerfer (Edapt Ignite)
• Eike Stepper (CDO Ignite)
• Saurav Sarkar (EMF Query Ignite)
• Mariot Chauvin (EEF and GMF Ignites)
• Cedric Brun (EMF Compare Ignite)

Table of Contents

1     Introduction

2     Example Model

3     Modeling

3.1      Code Generation

3.2      Model refinement

3.3      Why is this better than writing POJOs?

4     EMF API

5     Import Sample Solution

6     AdapterFactories

7     EMF Data-Management

8     EMF UI

9     Additional EMF-based Technologies

1        Introduction

For the question “What is EMF” we borrow the description from the EMF website:

“The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.”

It is noteworthy that EMF has also been a stable standard for many modeling technologies.

We suggest using EMF for any structured data model you have to create in Eclipse, especially if it gets stored, displayed and modified in UIs. The basic EMF workflow is very pragmatic; a model is created defined in the Ecore format. Ecore is basically a sub-set of UML Class diagrams. From an Ecore model, you can generate Java code.

Later in this tutorial we will have two running instances of Eclipse. In the first instance, the “IDE”, we will define the model and generate code from it. The second instance, the “Runtime”, will be started from the IDE and contain instances of the generated model.

2        Example Model

In this tutorial we will create an example model for managing a bowling league and tournaments. A League contains an arbitrary number of Players. A Tournament consists of an arbitrary number of Matchups. A Matchup always contains of two Games. A Game is a list of frames (the score) and is assigned to a certain Player. Finally a Tournament has an Enumeration determining the type of the Tournament.

In the next step, we will show how to create this model and generate code form it.

3        Modeling

We will create our example model in EMF to generate the entity classes for our application. The first step is to create an empty modeling project in your workspace:

The essential part of the modeling project is the model itself, defined in the format “Ecore”. Please create a new “ecore” file in the model folder in your new modeling project. We will name the file “bowling.ecore”:

Click finish to create the model. It will be opened in the default Ecore editor. This editor allows defining Ecore models in a tree-based view. There are several additional possibilities to define Ecore models, including graphical modeling, textual modeling, Java annotations and import from UML tools. We will stick to the default editor in this tutorial and shortly demonstrate the graphical editor for Ecore.

In the tree of the Ecore editor you can create and delete model elements as well as modify the structure of your model via drag and drop. Properties of model elements can be modified in a second view, which opens up on double-click or right-click => “Open Properties View”.

First, give the root package of your new model a name and an URI. This is used to identify the model later on. Name the package “bowling”, set the Ns Prefix to “org.eclipse.example.bowling” and the Ns URI to “http://org/eclipse/example/bowling ”:

Now, we can define our model elements as children of the root package. Please right click the root package and create a new EClass and name it Player.

From the context menu of an EClass, you can add EAttributes and EReferences to it. Create an EAttribute and open the Property view for it. The properties of an EAttribute define its name, its data-type and other properties, which we will cover later in this tutorial. Add an EAttribute to the Player, name it “name” and assign the EType “EString” (java.lang.string). Repeat this step and add a second EAttribute named “dateOfBirth” of type “EDate”.

EMF models usually build up a structured hierarchy, meaning model element instances, e.g. the Player “Jonas” are contained in a specific container object. This provides a tree-structure, which is useful for navigability and allows for serialization. This tree structure is often referred to as containment tree. In our model, Players are contained in a League. Please note that this also implies that every Player is referenced by exactly one League, thus cannot be part of more than one League. Therefore EMF will automatically take care that a player cannot have more than one league. If you add a player to another league, its reference to the original league vanishes.

Create a second EClass and name it “League”. To identify the League, also create a EString attribute called name. The next step is to create a EReference between League and Player by right-clicking on the League model element. Name the references “players”. Set the EType of the reference to “Player”. As a League can contain an arbitrary number of Players, set the upper bound to “-1”, equivalent to “many”. Finally set the property Containment to “true” determining that the EReference is a containment reference.

After this first model iteration, we can already generate code from it. EMF provides an example editor to create and modify model instances. This allows us, to initially test the created model, before we further refine and add more EAttributes and EReferences in a second iteration to complete the example model.

3.1      Code Generation

In this step, we will generate the entities from the Ecore file we have created. Please note that you can regenerate the entities again, if you need to change you model. EMF can deal with simple changes like adding model elements or EAttributes. If you have complex changes, like moving an attribute to another class, you would have to migrate existing instances of the model. This is supported by the EDAPT framework.

To generate entities, we have to create a generator model file first. This file allows configuring properties for the generation, which are not part of the model itself, for example the plugin and subfolder, the source code is generated to. Please create a new generator file in the model folder and select our previously created Ecore as a source model.

In the root node of the generator model, you can set the properties for the code generation. In the tree of the generator model, we can set properties for every generated entity. For the first code generation, we just use the default settings. Based on the generator model, we can now generate the source code. EMF allows generating four different plugins for a defined model:

• Model: The model contains all entities, packages and factories to create instances of the model.
• Edit: The edit plugin contains providers to display a model in an UI. For example the providers offer a label for every model element, which can be used to display an entity showing an icon and a name.
• Editor: The editor plugin is a generated example editor to create and modify instances of a model.
• Test: The test plugin contains templates to write tests for a model.

To generate the plugins, right click on the root node of the generator model and select the plugin. For our tutorial, please select “generate all”.

Before we look at the generated code, let’s first start the application and create an entity of our model. Please right click on the model plugin and select “Debug as => Eclipse Application”.

Please create a new empty project and a bowling model. This file will contain a serialized version of our model instance.

Select League to be the model object. This determines the root object of the model instance we are about to create.

The generated editor for model instances works similar to the Ecore editor. Model element instances can be created via a right-click, EAttributes can be modified in the properties view. Please name the League and create two Players. On save, all created instanced are serialized in the XMI file “league.bowling”.

3.2      Model refinement

Let`s switch back to our IDE Eclipse environment, complete the model and regenerate the source code. In this second model iteration we will add different type of EReferences, as well as EEnums and Multi-EAttributes. First please add the following classes to the bowling model:

• Tournament
• Matchup
• Game

These classes model the results of bowling tournaments build up a second tree in our model. Therefore we add containment EReferences from Tournament to Matchup and from Matchup to Game. Following the bowling rules, a Matchup consists of two Games (each from one Player). We model this by setting the upper bound and lower bound of the EReference “games” of the EClass Matchup to “2”.

Furthermore we defined that the EReference between Matchup and Game is bi-directional. That means, the reference can be navigated from both ends. Therefore we have to create a second EReference from Game to Matchup and bind both EReferences. EMF will take care of the bidirectional synchronization. In other words adding a matchup to a game will automatically add the game to the matchup.

Please add a EReference to Game called “matchup” with the EType “Matchup”. By setting the EOpposite to the EReference “games”, both EReferences are coupled bi-directionally. Note, that the property “Container” will automatically be set to true.

The next step is to add a cross-EReference. In contrast to containment EReferences, cross-referenced model elements do not contain each other. In our model we add a cross EReference from Game to Player named “player”. Let both, container and containment properties “false”. An arbitrary number of games can be assigned to a Player now; the Player is still contained in a League.

As a final mandatory step, we will create an EEnumeration for the type of a tournament. A tournament can be of type “Pro” and “Amateur” in our model. Please create a EEnum by right-clicking on the root bowling model package, just like creating a class. Add two EEnum Literals to this EEnum.

Please add an EAttribute to the EClass Tournament, name it “type” and set the EType to “TournamentType”.

The extended example model contains more EAttributes and EReferences to be added including all basic types and some special cases as the Multi-Integer EAttribute in Game. Depending on your time, please model the following features:

Player

• height: EDouble
• isProfessional: EBoolean

Game

• frames: EInt, UpperBound = 10

After applying complex changes to the model it is always a good idea to validate it, done with a right-click on the model root in the Ecore editor. Let`s do something wrong in the model and set the lower bound of the EAttribute “games” (in Matchup) to 3. As the upper bound is 2, this model doesn`t make too much sense. This will be detected by the model validation, something which is impossible in plain Java Code.

After this model refinement, we will re-generate the code to reflect our changes. Start the runtime Application again and create a second model “tournament”. Add a Matchup and  two Games. To add assign the Games to Players you will have to load the “league” model created before. Select “Load Ressource” from the menu “Bowling Editor” and select the first model file. Now, link the Games to the Players in the properties view.

3.3      Why is this better than writing POJOs?

You might ask, why to use EMF instead of creating the model just writing plain POJOs. Without considering benefits like the generated editor for rapid testing and all additional frameworks available for EMF, let`s look at two very simple and exemplary benefits.

Before we even look at the generated code (we will do that in a minute), let`s consider the amount of code we have just produced. The Eclipse metrics plugin tells us, we have generated over 1000 LOC, while only 150 is part of utility classes. Even very simple code is considered to be worth 1$ per LOC. So we have just earned 1000$ just by clicking some buttons?

In the next part, we will explore the EMF API of the code we have just generated. You can follow this blog to get notified about new posts. You can download a PDF version of this tutorial here.

Tags: emf, modeling, munich

I am happy to announce that EclipseSource is finally entering the modeling world and would like to introduce Max and Jonas as our new team members in Munich. Both are well known in the modeling community for leading the Eclipse projects,  EMFStore and EMF Client Platform.

With our expansion to Munich we can now better accommodate our customers in southeast Germany, Austria and Switzerland. But beyond the geographic expansion it is a big step for EclipseSource to enter the world of modeling, as we have been hesitant to get involved deeply with the technology over the last decade.

Two things made us change our minds: EMF’s versatility and the availability of a great team. Max and Jonas have proven their EMF expertise with the EMFStore project and in joint projects with EclipseSource.

Now, you no longer need to hesitate to contact us with your Eclipse Modeling questions and challenges. We are looking forward to it.

Tags: emf

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

Did you ever wanted to know how features find their way into Eclipse and became a part of a huge release like Eclipse Helios? What role do committers play? What is the part of the community? How do different projects collaborate with each other?

For all of you Benjamin Muskalla and I will give the answer on the Eclipse Helios DemoCamp in Darmstadt on July the 14th. If you are around feel free to step by.

Tags: democamp, eclipse, emf, helios, rap

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

Tags: eclipse, eclipsecon, emf, helios, new and noteworthy, rap, Single Sourcing, talks

As they already did in January – the compeople AG (the folks behind the Riena project) are organizing another Stammtisch on May, 27th. It will take place in their offices in Frankfurt am Main, Germany. As Ian already pointed out, “Germany seems to love their DemoCamp” – but that’s only partly true: We also love our Stammtisch

Ralph will start the official part of the evening with some insights of the Eclipse Foundation and news about the open source community. In addition Ekkehard Gentz will give an introduction to UIs for business applications based on Riena, UML and oAW. And last but not least Jochen Krause will give some cool demos of new features for upcoming RAP 1.2 release.

After so many interesting topics, I hope to have some hot discussions over several cold beverages in the evening. At 7pm they are organizing a get together at the Chicago Meatpackers restaurant. Please let them know, if you participate by sending a mail to Andrea (dot) Drews (at) compeople (dot) de.

Really looking forward to see you there – I think it is going to be a great Stammtisch!

Tags: eclipse, emf, rap, riena, stammtisch