UNICASE

What every Eclipse developer should know about EMF - Tutorial at EclipseCon

2011-03-16T04:18:00.000-07:00

We are looking forward to present the tutorial „What every Eclipse developer should know about EMF“ at EclipseCon next week, Monday 9.00 am. Let us shortly explain how we got to that idea. The starting points for this idea were:

Even if modeling is a very active area in the Eclipse community, there are many developers who have no experience with EMF at all
Many of those developers complain that it is hard to gain an initial overview about modeling techniques and frameworks. Eclipse is always not only about knowing a specific technology but also knowing about the Ecosystem.

So the goal of the tutorial is to tackle both issues and introduce “What every Eclipse developer should know about EMF”. The title is of course inspired by the great talk about dependency injection by Sven Efftinge on Eclipse Summit`10.

For the first issue we created a basic EMF tutorial, which covers EMF modeling and gives entry points for the most important topics such as UI programming and data management. The second issue is a little bit harder to resolve. How could we give a good overview about different modeling technologies? There were two great things influencing us. The first was the Model Symposium at Eclipse Summit, which showed us how many short talks can provide a nice overview of many technologies. The second influence was the Ignite Competition held by the Eclipse Foundation. An Ignite talk consist of 20 slides, switched automatically every 15 seconds and is therefore exactly 5 minutes. This format forces to concentrate on the most important facts instead of going into detail about specific topics. We combined these two ideas and invited Project Leads of modeling projects to introduce their projects with an Ignite talk during the second part of our tutorial. We hope this will provide a good overview of available technologies and therefore cover the second part of “What every Eclipse developer should know about EMF”.

We are looking forward to welcome you as participants of this tutorial. As a preparation for the hands-on part, we kindly ask you to have a (fresh) installation of the Eclipse Modeling Edition (Helios).

New Logos for EMFStore and EMF Client Platform

2011-03-10T06:58:00.000-08:00

...long story short: we are proud to present the new logos for the EMFStore and the EMF Client Platform:

EMFStore

EMF Client Platform

A generic widget for multi attributes for the EMF Client Platform

2011-03-02T03:24:00.000-08:00

The EMF Client Platform provides a generic and reflective editor for arbitrary EMF models. All visible attributes and references of a model are rendered in an form-based editor with generic widgets.
However, the EMF Client Platform UI did not yet support multi attributes, for example an Integer attribute with a multiplicity of 3. During the implementation of a multi attribute widget we had to make several decisions. The solution for multi-attribute is not as intuitive as it was for single attributes. We came up with several inital propsals and combined the best parts of each of them. The most important questions were the following, which are addressed by the proposals shown afterwards.

What kind of manipulation operation is required (besides add/change/delete)?

Change order --> proposal 2,3
Sorting --> proposal 2

How can the representation look like?

List view --> proposal 2,3
Single-Control-Composite-View --> proposal 1

How to manipulate data?

Implicit (no buttons) --> proposal 1
Explicit (buttons / keystrokes) --> proposal 2
Combination --> proposal 3

How to design buttons?

Text Buttons --> proposal 2
Image Links --> proposal 3

Proposal 1: minimal look N feel

new entries are created when you start typing in the bottom one (another empty field appears)
changes are saved whenever a field is edited
entries are deleted by deleting a field's content

PRO/CONTRA:
+ intuitive usage
+ simple style that fits into every editor window

- no multiselection in order to delete/move several entries at once
- there has to be one "empty" value (here: "") that is not stored
- no change order functionality
- can become pretty big because of missing scrollbars (but they could be implemented)

=> disadvantages led to idea 3

Proposal 2: the widget works with a list - so let's create one in the GUI

new entries are created by clicking the "+" Button (Pop-Up appears)
changes can be made by selecting an entry and clicking "..." (Pop-Up appears)
entries are deleted by selecting them and pressing Del
entries are moved up and down with the corresponding buttons (not visible in the screenshot)
Sort funtionality by clicking the button
windows are automatically resizeable according to content

PRO/CONTRA:
+ intuitive representation and manipulation of the list
+ easy implementation of global listeners (for keystrokes) because there aren't individual
buttons for each entry (as in idea 3)

- much clicking because of pop-ups

Proposal 3 and Final Solution: combine look and feel of proposal 1 with more functionality

new entries are created when you start typing in the bottom one (another empty field appears)
you can add an "empty" new entry by clicking the plus button
changes are saved whenever a field is edited
entries are deleted by clicking the red cross
entries are moved up and down with the corresponding buttons

PRO/CONTRA:
+ style still quite simple, the buttons don't "jump out" - fits into every editor window
(the button design could be changed easily if necessary)
+ each single-element-control can be designed without any restrictions (see difference between
String and integer) depending on its type

- no multiselection in order to delete/move several entries at once

Eclipse Stammtisch munich

2011-02-22T11:58:00.001-08:00

Greetings to all Eclipse Folks from the longest Eclipse Stammtisch ever :-)

We have good food, good beer and good conversations. Thanks to Ralph for the drinks!

Position:Kuglerstraße,München,Deutschland

Eclipse Stammtisch München, few seats available

2011-02-15T00:37:00.000-08:00

The democamp in November proofed, that there is a large and active Eclipse community in Munich. We have already 31 registrations for the Eclipse Stammtisch on February 22nd 19.00 at Unionsbräu.
There a only 9 seats available to fill the worlds longest Eclipse Stammtisch (as stated by Ekke):

We are looking forward to meet you there and we will make a reservation for additional tables, if the "long" table is full.
Please help us to organize the event by registering here.

Test Model Generator for EMF

2011-02-08T00:56:00.000-08:00

In several EMF projects I have seen a test model generator. The goal is to generate model instances of a certain model, which can be used for testing. For some tests, it is only important to have an arbitrary instance of a certain size, and sometimes it just makes sense to create arbitrary model instances to detect failures. We (Andrea, Metteo, Hong and Stephan) have developed a geneeirc generetor appyable for arbitrary ecore models. I am interested in feedback on this, we plan to make it available under EPL in the EMF Client Platform Project.

Models can be created like this:

1. Generating Ecore model (Library) without using any further Configuration:

2. Generating Ecore model (Ecore ecore) using ModelGeneratorConfiguration:

3. Changing values of the configuration (OCL model):

The curious case of VisibleWhen

2011-02-01T00:39:00.000-08:00

Almost every Eclipse developer has used it, but I have seen many cases, where the VisibleWhen tag is just copied. It is used to define the visibility of the menu item of your plugin. As an example you could show a specific menu item in the navigator right click menue of a certain type (e.g. a Java File). This post describes a typical example of the VisibleWhen in detail, thanks to Stephan for wrapping thing up.
A very easy way to test the VisibleWhen condition is to register an example command on Java elements. They can be created in the target (the compiled and started Eclipse instance). In this example I register an example command in the right click menue of an ICompilationUnit (Java Class) and an IJavaProject (Java Project). The following screenshots shows these two elements in the target.

The following example shows the menue entry, if one IJavaProject is selected.


      <menucontribution allpopups="false" locationuri="popup:org.eclipse.jdt.ui.PackageExplorer">
         <command commandid="menucontributions.commands.sampleCommand">
            <visiblewhen checkenabled="false">
               <and>
                  <iterate ifempty="false" operator="and">
                     <instanceof value="org.eclipse.jdt.core.IJavaProject">
                     </instanceof>
                  </iterate>
                    <count value="1">
                </count>
               </and>
            </visiblewhen>
         </command>
      </menucontribution>
   </extension>

-By setting the attribute checkEnabled to true the menu will check if the corresponding handler has been enabled; if it has been enabled then it will show the menue entry, otherwise it will not.

- is combining the conditions: In this case the "iterate" condition AND the "count" condition have to be true. Otherwise the item isn't shown.

- iterates over all selected elements and checks the conditions underneath for every element. If you directly right click an item, only one element is selected. If multi-selection is allowed, many elements can be selected on right click. ifEmpty=false means that if nothing is selected, the menu item isn't shown. operator="and" says that the conditions (in this case there is only one instanceof condition, but there can be more) must be true for all selected elements. operator="or" will show the menue entry, if the condition is true for at least one selected element.

-instanceof checks for every selection if the selected element is an instance of the type someClass in this case org.eclipse.jdt.core.IJavaProject.

- With count you can set the number of selected items. If more or less are selected, the menu item isn't shown.
You can also use th following parameters:

*	Arbitrary number of items
?	Zero or one item
+	One ore more items
!	No items

The following example shows the menue entry if exactly two items are selected and both items are either an ICompilationUnit or an IJavaProject:

<visiblewhen checkenabled="true">
               <and>
                  <iterate ifempty="false" operator="and">
                     <or>
                        <instanceof value="org.eclipse.jdt.core.IJavaProject">
                        </instanceof>
                        <instanceof value="org.eclipse.jdt.core.ICompilationUnit">
                        </instanceof>
                     </or>
                  </iterate>
                  <count value="2">
                  </count>
               </and>
            </visiblewhen>

Automatic Bug Reporting in Eclipse

2011-01-20T04:04:00.000-08:00

Recently I have been looking for a framework for Eclipse to automatically report bugs, which result in a error message or an error log entry. The reason is quite easy: whenever something goes wrong while someone is using your product or framework, you would like to know that to fix the issue. Many commercial products like MS Office offer the feature to automatically submit crash reports to the vendor. Surprisingly, I did not find any framework offering this feature for Eclipse. There is an implementation within Window Builder, but it is (not yet) available stand-alone.

I would like to ask for opinions about the following feature list, whether they are required by more poeple or projects and how this issue is solved in other projects:

Features
When an error occurs, there should be an option to view relevant errors and the information to be sent to a specified location such as an email address or the development team.

The required features are:

A listener to recognize that an error has occurred. This listener should include the error log as well as runtime exceptions.
An ability to filter the listener by different categories such as by
packages or projects, i.e. org.unicase.*, Emf, etc. Depending on the filter, the
UI for reporting the bug appears.
A UI element showing the relevant errors and collected information such as
operating system, java version, and target definition. The collected information should be transparent for the user for privacy reasons.
Sending the collected data to a specified email address, bugzilla or google group

Furthermore you could think about several refinements, which improve the user acceptance such as an aggregation. In case there are many relevant errors, the framework should aggregate them and only ask the user once in time.
I am interested in any feedback on this.

EGit Tutorial for Beginners

2011-01-19T02:24:00.000-08:00

Matteo recently created a very comprehensive tutorial for EGit, which I would like to share. The tutorial describes all basic features of EGit including screenshots. It is meant for people who are just starting to use EGit.

Installing EGit into Eclipse
Open the Eclipse Wizard to install new software Help => Install New Software. Insert http://download.eclipse.org/egit/updates after Work with: and hit Return. Select Eclipse EGit (Incubation) as a child from Eclipse Team Git Provider (Incubation). You don't have to install any other plugins. Click Next and confirm your selection in the following window pressing Next again. Finally, accept the terms of license agreement and click Finish to start the installation. After the installation has finished, restart Eclipse to work with EGit

EGit Configuration
Every commit in EGit will include the user's name and his email-address. These attributes can be set in the Preferences-window Window => Preferences. Navigate to Team => Git => Configuration and hit the New Entry... Button. Enter user.name as Key and your name as Value and confirm. Repeat this procedure with user.email and your email-address and click OK in the Preferences-window.

Creating Local Repositories
First ,you have to create any project you want to share via your local repository. For later purposes it would be useful to also add a class to your project. After you have created your project, rightclick it and navigate to Team => Share Project... . Select Git as the repository type and hit Next.

In the following window select your project, hit the Create Repository-button and click Finish. The repository will be assigned automatically.

The created repository will be empty, although the project is assigned to it (note the changed icons: the project node will have a repository-sign, the child nodes will have a question mark-sign, ignored files, e.g. the bin-directory, won't have any sign at all). Before you can commit the files to your repository, you have to add them. Simply rightclick the shared project's node and navigate to Team => Add. After this operation, the question mark-signs should have turned into plus-signs. The last thing to do is to commit the project: Rightclick the project node and select Team => Commit... from the context menu. In the Commit-wizard, all files should be selected automatically. Enter a commit message (the first line should be headline-like, as it will appear in the history view) and hit the Commit-button. If successful, the plus-signs should have turned into repository-signs as well.

Commit
To save changes done in your workspace into your repository, you will have to commit them. After changing files in your project, a ">" sign will be added, right after the icon, telling you the status of these files is dirty. Any parent folder of this file will be dirty as well.

If you want to commit the changes to your repository, rightclick the project (or the files you want to commit) and select Team => Commit... . This will open a new window, allowing you to select the files you want to commit. Before you can commit the files, you will have to enter a commit message in the upper textbox. After you're done, click Commit to commit the selected files to your repository.

Note that the status of the changed file is Mod., not staged. By staging the files before you commit (see section Additional Information), you can change the status to Modified (and the dirty sign to a staged icon).

If you realize your previous commit was incomplete (e.g. you missed to commit a file) or your last commit's commit message was wrong in any way, you might want to check Amend previous commit. This will merge the current commit and the previous commit into one, so you don't have to perform an extra commit (and maybe cause confusion). However, this should only be done if the previous commit hasn't already been published to a shared repository.
Another option is Show untracked files. By checking this checkbox, new files you created, but did not add yet, will be available for you to select. Checking untracked files will add them to your repository, after clicking Commit.

Adding Files
To add a new file to the repository, you will have to create it in your shared project first. The new file will, again, appear with a question mark-sign.

Rightclick it and navigate to Team => Add. The question mark-sign will turn into a plus-sign - the file is now tracked by Git, but not yet commited. All of the file's parent folders should now have a staged-sign (more on that later). In the next commit, the file will be added to the repository, therefore the plus-sign will turn into a repository-sign. The repository-signs of all the file's parents (packages/project...) will turn into staged-signs.

Reverting Changes
If you want to revert any changes, there are two possibilities: You can compare each file you want to revert with the HEAD revision (or the index, more on that later) and undo some or all changes done. Otherwise you can hard-reset your project, causing any changes in the working directory to be reverted.

Revert via Compare
Rightclick the file you want to revert and select Compare With => HEAD Revision. This will open a comparison with the HEAD Revision, pointing out any changes done. If you want to completely revert your file, hit the Copy All Non-Conflicting Changes from Right to Left-button in the Java Source Compare-toolbar. If you only want to revert several lines, select each line and hit the Copy Current Change from Right to Left-button from the toolbar each time. After any of these two you will have to save either the comparison or your local copy of the file to complete the revert operation.

Revert via Reset
To reset all changes done to your project, rightclick the project node and navigate to Team => Reset... . Select the branch you want to reset to (if you haven't created any other branches, there will be just one) and choose Hard as a reset type. By confirming this operation, all changes will be resetted to this branch's last commit, including all changes done in the workspace (and index, more on that later).

Cloning Repositories
Note: For this and some of the following (especially Fetch/Push) sections, you might want to use https://github.com for creating your own remote repository. This might be useful to perform several actions and gain some insight.

In order to checkout a remote project, you will have to clone its repository first. Open the Eclipse Import-wizard (e.g. File => Import), select Git => Projects from Git and click Next. This will open the Git Repository Selection. Hit the Clone... button to open another wizard for cloning Git repositories.

First you will have to enter the repository's location and connection data. Entering the URI will automatically fill some fields, if any other are required, fill these and hit Next. Select all branches you wish to clone and hit Next once more.

Choose a local directory to save this repository in.

Warning: I ran into some errors when choosing the default directory, as this was my workspace directory and I couldn't import projects into a subfolder in my workspace as Eclipse prohibited this. If you can't import projects from a repository, try changing this directory!

After clicking Finish, the cloned repository should appear in your repository list.

To import the projects, select the cloned repository and hit Next. Select Import Existing Projects and Try to share newly created projects automatically (otherwise you would have to share the projects manually) and hit Next.

In the following window, select all projects you want to import and click Finish. The projects should now appear in the Navigator/Package Explorer (note the repository-sign in the icons - the projects are already shared)

Creating Branches
To create a new branch in your repository, rightclick a shared project and navigate to Team => Branch... from the context menu. Select the branch you want to create a new branch from, hit New branch and enter a name for the new branch.

The new branch should appear in the branch selection window. If you would like to checkout the just created branch, select it and click Checkout.

Merge
To merge one branch into another, you will have to checkout the branch you want to merge in to. Rightclick the project node and navigate to Team => Merge... . Select any branch (other than the checked out branch) and hit Merge.

The merge will happen automatically and pop up a result window telling you about the outcome. The possible results are Already-up-to-date, Fast-forward, Merged, Conflicting, Failed. A Conflicting result (see picture below) will leave the merge process incomplete, you will have to resolve the conflicts (see next chapter). A Failed result may occur when there are conflicting changes in the working directory.

Resolving Conflicts
If your merge resulted in conflicts (note the red sign in the file icons), you will have to resolve these manually. Open the conflicting files and scroll to the conflicting changes (<<<<<<<<<<

After you are done merging, you will have to tell Git that the conflict is resolved. To do so, Add the files and Commit afterwards to complete your conflicting merge.

Fetch
When cloning remote repositories, git creates a copy of the branches as local branches and as remote branches as well. A Fetch-operation will update the remote branches only. To update your local branches as well, you will have to perform a Merge-operation after fetching (Fetch and Merge is Pull in the original Git). To perform a Fetch, select Team => Fetch From... from the project's context menu. Enter the repository you want to fetch branches from (if you cloned this repository, the remote will be selected as default).

In the following window you will have to select what you want to fetch. By default, all branches are selected.

The result of the Fetch-operation will be shown in a final confirmation window:

Push
Local changes done to your local branches can be pushed to remote repositories causing a merge from your branches into the branches of the remote repository (X pulls from Y is the same as Y pushes to X). The Push-wizard is pretty much the same as the Fetch-wizard. First, rightclick the project node and navigate to Team => Push... . Enter the repository you want to push your branches to (the default for this will be the same as the Fetch-default if you didn't configure a Push-default) and hit Next.

Choose the branches you want to push or click Add all branches spec if you want to push all branches. You can also select branches you want to delete from the remote repository. If you are done hit Finish.

A final window will show the results of the Push.

Synchronize
Comparisons between branches are done via the Synchronize-operation. Rightlick the project node and navigate to Team => Synchronize... . Select the branches you want to compare, include local uncommited changes if you like, and hit OK.

To compare the branches you may want to switch to the Synchronizing perspective. You might get a more detailed view of the several changes. The following picture shows a Synchronize in the Java perspective.

An example of a Synchronize-operation in the Synchronizing perspective:

History View
To show any shared file's history, rightclick it and select Team => Show in History. This will open the History View, granting an overview of the commits and allowing you to perform several actions (compare, creating branches/tags, reset...). Every commit you select comes up with a revision comment and revision details. The revision comment (bottom left corner) includes parents, children, commit message, changes... whereas the revision details (bottom right corner) name the changed files and the actions performed upon them (A=ADD, M=MODIFY, D=DELETE). Selecting a file in the revision details will scroll the revision comment to the changes of that file.

Creating Patches
EGit lets you create patches in Git patch format or default diff patch format. However, EGit doesn't support applying patches in Git patch format, yet. They could be applied via the command line though. Any patch can only include one commit, that is from a parent to its child (single parent, no merging allowed). To create a patch you have to open the History View first (see previous section). Rightclick a commit you want to create a patch for (this must be a child with exactly one parent) and select Create Patch....

Select either Clipboard or File and hit Next. Export this patch in Git patch format if you like (reminder: can't be applied via EGit yet) and click Finish. The resulting patch can be applied to the parent commit via Team => Apply Patch....

Repository View
The repository view is useful when working with branches/tags and executing operations on them as well as handling remote repositories and granting an overview over all your repositories. To open this view, select Team => Show in Repositories View from any file's context menu.

Additional Information

Icon Decorations/Signs

ignored: The repository treats these files as if they were non-existent (e.g. the bin-directory by default). Add a .gitignore file or Team => Ignore to ignore a file.

untracked: Any file known, but not yet recorded. To track a file, add it or select the Show untracked files-option in the commit-wizard and commit it directly.

tracked: Any file known to and recorded by the repository.

added: Any file known to the repository, but not yet commited. Perform a Commit to change this file's status to tracked.

removed: Any file that shall be removed from the repository. For this icon to appear Team => Untrack has to be performed. By deleting the file from the workspace, the file will disappear (and therefore no icon will appear). However, it will still be removed from the repository with the next commit.

dirty: Any tracked file with changes, that are not yet added to the index.

staged: Any tracked file with changes, that are already added to the index.

partially-staged: Any tracked file with changes, where some changes are already and others are not yet added to the index.

conflicted: Any file where the merge result caused a conflict. Resolve the conflicts and perform an Add-operation to change this file's status.

assume-valid: Any modifications won't be checked by Git. This option can be activated via Team => Assume unchanged. However, it can only be turned off via the command line without taking further actions. Performing a Reset-operation resets this status as well.

IndexThe index, sometimes referred to as staging area, is an area between the working directory and the repository. Any change done to any file will change this file's status to dirty (see above). Any dirty file can be added to the index with an Add-operation. The file's status changes to staged. You can compare files to the index and reset the index without resetting the workspace. In original Git, files had to be added to the index before performing a Commit-operation. This is not necessary in EGit, as Team => Commit allows to commit unstaged changes.

Reset Types
You can reset your current branch to any other branch, tag or commit you want. Rightclick any commit in the History View and select Reset. There are three options available:

Soft:
The current branch's tip will point to this branch/tag/commit. Changes in index and working directory, however, won't be resetted.
Mixed:
Same as a soft reset, only that the current index will be replaced by the selected branch/tag/commit's index. The working directory stays unchanged.
Hard:
All changes will be reverted to the selected branch/tag/commit. Uncommited changes will be lost, therefore this operation has to be confirmed.

Useful pages

To create your own remote repositories and perform operations on them, you might want to register at https://github.com. As long as your repository is public, github is free.
A tutorial with more information on certain options and actions: http://wiki.eclipse.org/EGit/User_Guide

Please feel free to post any comments or feedback. Thanks to Matteo for warpping things up.

Eclipse Stammtisch Munich rescheduled to February 22nd

2011-01-10T03:03:00.000-08:00

Due to many requests, we have decided to reschedule the Eclipse Stammtisch in Munich to February 22nd. We have already made a reservation for this table:

at Unionsbräu. We will meet at 7pm.

If you plan to attend, we kindly ask you to fill out this form. This helps us to organize the event.

Eclipse Stammtisch Munich, February 7th 2011

2010-12-14T04:00:00.000-08:00

As Ekke already blogged here, we will organize a "Eclipse Stammtisch" in Munich. The first one will be on February 7th in Unionsbräu Munich - Haidhausen. The goal of the "Stammtisch" is to meet informally and share interesting information about Eclipse related topics. You are also welcome, if you do not talk about Eclipse only :-)
If you want to attend the "Stammtisch" or you want to get notified about future "Stammtischs", please help us to organize the event and fill out this form. (Short link: http://bit.ly/gMWv2c)

We will inform you about the details of the event.

Hope to see you there!

EMFStore and EMF Client Platform Ignite Talks

2010-12-06T04:29:00.000-08:00

Inspired by the "Ignite-Fever" we have recorded two more Ignite talks about the EMFStore and the EMF Client Platform. These are short versions of the talks we have submitted to EclipseCon 2011 (EMFStore Ignite Talk was updated in March 2011):

Here is a link to the Submission: https://www.eclipsecon.org/submissions/2011/view_talk.php?id=2011

Here is a link to the Submission: https://www.eclipsecon.org/submissions/2011/view_talk.php?id=2012

Eclipse Democamp Munich

2010-11-23T19:22:00.000-08:00

We have changed the room, we have change the room again, but we finally did it. The Eclipse Democamp took place yesterday and was a great success. We were able to include all registrations. The room was packed, but everybody got a seat. Thanks to all the volunteers!

Here is a wrap up of the talks:

Bernhard demonstrates the Eclipse Prolog EMF Transformation Engine. It allows to define model transformations using constraints. The transformation itself explores possible solutions for transformations, which confirm to the defined constraints. He demonstrates this on a example from an automotive application.

Axel solves a very common problem with adpapters. He identified that the registration of many Adapters in EMF cause a performance problem. This is especially true if there are many adapters, which are not interested in an event. He proposes a solution based on hashmaps. The filter of every event registration is distributed in several hashmaps. This even allows fo and and or terms. The event filter can be defined via a custom API. It would be an interesting problem to transform existing filters written in Java to the more effective format.

Maximilian an me presented in a lightning session the EMF Client Platform, the EMFStore as well as the JDT Integration of the EMFStore. I do not know what exactly we have talked about :-)

Markus demonstrates advanced feature of Edapt (Cope). The tool allows to automatically migrate model instances, when the meta-model is changed. Therefore, changes on the meta-modell are recorded. In the talk he focused on an advanced feature. It allows to diff two existing versions of a meta-model which are already created without tracking the changes. The tool semi-automatically supports the user to recover the changes, which were done. Also he demonstrates how to define custom constraints.

Kai presented how to use CSS Styling in Eclipse 3.x. As no manager is in the room, he even shows source code :-) He points out the importance, that application have to be styled corresponding to an existing template, provided by a designer. The CSS feature of 4.x can also be used in 3.x. Themes can even be switched during runtime. All required sources and his slides can be soon found at the democamp wiki.

Ekke presented his lessons learned from developing mobile business applications based on Eclipse for Blackberry, IPhone and Android Adroid. Ekke has developed a number of custom widgets to better support UI development on the different platform. However the challenges for these applications are not limited to the client side, there are many challenges for the server side also such as data transmission. A central paradigm in this context is the hollywood principle: don´t call us, we call you.

Then there was a short break...

After the break, Tom hold his famous and great Eclipse 4 talk. He summarized the news on the e4 project. He first explained that e4 started off on the wrong foot due to false communication. He clarified that it is not the main intention of e4 to move the eclipse platform to the web. Its main intention is a new and much more simple programming model. For this purpose it heavily employs dependency injections. This decouples the implementations from the actual framework classes and eases testing a lot. Also with e4 all information on the workbench are represented in an EMF-based model which is rendered live. This means that all relevant information is concentrated in one place and can be modified there. This allows for more powerful and easier access. For legacy applications e4 offers a compatibility layer and its goal is to support 99.9% of all existing RCP applications for 3.x. Tom pointed out that there are still problems due to missing tool support for debugging because of dependency injection.
Then, there was a short break...

Holger Staudacher has presented the current state of RAP. RAP allows to single source web applications and RCP applications. During his talk he was asked about performance of RAP. In response Holger and Benny Muskalla showed how RAP can be even faster than RCP and is still very responsive even for DND and custom widgets that directly draw on a canvas. Also numerous options for theming RAP were demonstrated. For the next release RAP is going to suppot SWT 3.7 and implement non-native scrollbars to better support theming of scrollbars also.

ETrice, presented by Henrik Rentz-Reichert, is a new Eclipse project which is currently in incubation and still gathering community. Its goal is to implement the ROOM language, a language for object-oriented modelling of event-based real-time systems. Also it aims at providing a tool set for working with this language including X-Text-based and Graphiti-based editors.

And finally Benny, who works now at Tasktop, adresses typical issues in the every day work of a developer: multi-tasking, searching and interruptions. He shows that developers spend almost half of their time with tasks like that, which is not coding itself. Also 90% of the stuff we see in out workbench is irrelevant for the current taks. Goal: avoid friction and disatraction. Instead: flow and focus. The proposed solution is integrating the tasks of a developer into the Eclipse workbench from various sources. Based on these tasks, the context of the developer can be filtered and also easily switched. Most important thing: we all can sleep longer :-)
Very nice talk, have to try that out.

The event has shown the high interest in Eclipse in the region. And the goal for the next event is "Fill the Audimax" :-)
Thanks to the Eclipse Foundation and EclipseSource for sponsoring.

How to find the Democamp in Munich

2010-11-22T13:16:00.000-08:00

The university building is probably one of the most confuing buildings in Munich. To avoid that anybody gets lost, please follow this description to find the Eclipse Democamp in Munich tomorrow:

The roomfinder points to a room which is just next to our room (our room is not available in the finder). Our room is 0607ZG.
The easiest way to get to the room coming from U-Bahn (U2) Theresienstraße is walking along Theresienstraße. Then enter the building from the north (entrance Theresienstraße) at the car gate. The gate is just in between the two bridges which cross the street. From this entrance, there will be guiding signs.

We strongly recommend to use public transport. The neariest public car park is this: [http://www.amaliengarage.de/geschaeft/anfahrt.htm] However this is approximatly a 15 minutes walk.

Funniest error message...

2010-11-17T03:08:00.000-08:00

I do not tell the frameworks name, but I have just received the funniest error message since a long time:

How to version Ecore files

2010-11-16T02:40:00.000-08:00

Integrating the EMF Store to the JDT workbench.
This post summarizes our talk at the Eclipse Summit. Thanks to Adrian for wrapping things up…
Source code is managed by repositories such as CVS, SVN, GIT or others. Many projects store their EMF models, namely Ecore files in the same repository. This involves problems in handling conflicts and merges. The EMFStore is designed to version EMF model instances related objects. As Ecores are also model instances, the EMFStore is also able to version them.
At the Eclipse Summit we presented an integration of the EMFStore into the JDT workspace. The aim of the EMF Store JDT integration is that it gives developers the possibility to manage Ecores not only by the current repository, but in addition by the EMF Store. The integration is unobtrusive in order to keep the development process mainly untouched. This means that the user can use the wellknown actions like commit and update provided by the current used source repository. An EMF Store will lead to an improved conflict handling for EObjects. The EMF Store JDT also deals with the problem that some developers might have the EMF Store JDT installed but others do not. To keep both repositories in synchronization, changes that are done by a user with the EMF Store JDT plug-in will be stored redundant on both repositories.
This post shows various ways how merging issues during collaborative work can be solved and especially how the EMF Store can improve and reduce these merging conflicts.

Use case to demonstrate a usual issue
As an example for a conflict in an Ecore, we will use the default EMF example “library”. Let’s assume this library project is already shared via SVN and the initial state is checked out by user A and user B. The relevant part for this article is visualized in screenshot 1.


Screenshot 1: Library Ecore example

Now user A changes the attribute “name” of the class “Writer” from “name” to “author”. User B changes at the same time the upper bound of the same attribute from “1” to “2”.
At first user A commits the changes that were done to the project. This commit can be performed without trouble. Now user B wants to commit but user B cannot directly commit. SVN notifies the user about a conflict. This conflict can be now handled via “Text Compare”, “EMF File Compare” or if applied “EMF Store”.

Text Compare
This conflict can be inspected with the action “Synchronize with Repository”. The first comparison that can be used is the “Text Compare”. Screenshot 2 illustrates the differences between the local file and the current remote one. For a human being it is obvious that another user changed the value of the attribute name from “name” to “author”. In addition the local file got an additional attribute “upperBound” with the value “2”.

Screenshot 2: Text Compare

Since a local file is compared with a remote file, changes from the remote file can only be applied to the local one. The local file is shown at the left side and the remote file at the right side. To apply the remote change, that the attribute “name” has been renamed to “author”, the first entry from the list has to be selected. Than the button “Copy Current Change from Right to Left” has to be clicked.

Screenshot 3: Text compare- change applied

The button suggests that the remote change can be integrated to the local one. Unfortunately, the line where the remote difference has been discovered will be complete copied to the local one and the local line will be also kept. This circumstance is visualized in screenshot 3. This means a lot of post processing for the developer to select which changes should be kept in fact.

EMF File Compare
Since in the use case an Ecore file has been changed, an EMF File Compare is also available. The recognized changes are shown in screenshot 4. As the EMF File Compare knows about the structure of an Ecore file, better merging can be achieved. The upper part shows again the “Structural differences” view. This view shows exactly what has been changed. The user may even read that the attribute “name” has been remotely changed to “author”. The second change also displays that the upper bound has been locally changed from “1” to “2”.

Screenshot 4: EMF File Compare

As previously mentioned, this method compares a local file against a remote file. So changes can be only adapted to the local one. To get the change that the attribute name has been renamed to author, the respective change has to be selected and the button “Copy Current Change from Right to Left” has to be pressed. The result of this action is that the renaming will be locally performed and the author attribute has now the cardinality with the upper bound 2. At this point all merging has been successfully done and the commit can be finally performed. The preliminary conclusion is that the EMF File Compare is much more powerful than a simple diff is. But there is still room for improvement.

EMF Store JDT (1)
As the EMF Store JDT is an addition to already shared projects, the current used source repository can be used further on. To use the EMF Store for Ecore files, it is necessary to connect a local file to an EMF Store. To reach this, right click on the desired file and select from the context menu “Push to EMF Store”. A dialog appears where an EMF Store has to be selected. This dialog is displayed in screenshot 5.

Screenshot 5: EMFStore Project Selection

Right after a project has been selected the origin file has got an additional decoration that indicates that the file is under EMF Store control. This state can be seen in screenshot 6 for the file library.ecore. The version in the brackets is the EMF Store project version. This is currently 0, due to the fact, that the project where the library.ecore is stored, has not been committed yet. The following number 10 stands for the SVN revision of the file.

Screenshot 6: Ecore File under EMFStore Version Control

A commit of the library project will effect that other users will see as well that the file has been put under EMF Store control. Let assume user A has made this commit and user B updates the project. Now user A and B make the same changes as in the initial use case described. User A performs a commit as usual. First, the SVN commit dialog will be displayed and the user can enter a commit message. The user can choose which files should be committed. After pressing on OK the SVN commit has been confirmed and the commit dialog of the EMF Store will be displayed. Here the user can verify the changes in detail that will be committed to the EMF Store. The EMF Store commit dialog can be viewed on screenshot 7. User A confirms this by clicking on OK.

Screenshot 7: User A - EMFStore Commit Dialog

Now user B does a commit, too. Again, first, the SVN commit dialog will be shown and then the EMF Store commit dialog. But before the EMF Store commit dialog will be shown a message is shown to the user that the local EMF Store project is outdated as visualized in Screenshot 8. User B confirms the question with “Yes”.

Screenshot 8: EMFStore Project is outdated

All update changes are shown again in a dialog and the user can inspect if they should be applied to the local project or not. So here the user can recognize that the attribute name has been changed to author. After that the actual commit will be performed. The dialog will look very similar to screenshot 7, but the change operation will be that the “upper bound” of the attribute “author” has been set from “1” to “2” and the commit can be applied safely.
This means the user has not had to accomplish with merging issues. They could be solved autonomously without bothering the user. The user only had to update the local outdated version.
Someone may ask what has been committed to the SVN repository. Internally the EMF Store performs first the commit, it solves the merging conflicts and then the content will be also written back to the local file. This means the conflict is solved for SVN, so SVN committed the modified and conflict free version. So users who do not have the “EMF Store JDT” plug-in installed, will also get the correct version as they will update their project.

EMF Store JDT (2)
As previously seen, the EMF Store can merge situations where currently established tools get into trouble. Obviously, there are situations, where a merge cannot be solved without asking the user which changes should be kept. Such a situation can be caused by the following procedure: User A and user B have the same version checked out. If they do a change on the same object e.g. the same attribute, then it is not possible to decide independently which change should be kept. Let assume user A changes the attribute “name” of the class “Writer” as in the initial use case from “name” to “author”. User B changes also the name attribute from “name” to “writer”. The first commit can be safely applied but for the second one, the user gets a dialog, where the conflict will be shown. Such a conflict is depicted in screenshot 9.

Screenshot 9: EMFStore Merge Wizard

As visualized in screenshot 9 the user can read the conflict description:
“You have changed the name attribute of EAttribute “writer : EString” to writer. This attribute was changed to author in the repository.”
To solve this issue the user gets the option to easily decide how to solve it. Either one can click on “Keep My Change” or on “Keep Their Change” or an issue can be created.
If multiple merging conflicts exist, several of these sections will be shown. After all merging issues have been decided how to be solved, the decision will be applied and the commit can be finally executed.

Conclusion
The EMF Store JDT gives developers for a specialized kind of development artifacts a powerful tool how to avoid conflicts when working in collaboration with other developers. The only obstacle that has to be taken is that in addition to the already used source repository an EMF Store has to be selected when starting to add an EMF related file under EMF Store control. Since this is needed only once and only for one developer, the configuration overhead is minimal and the whole team can avail the benefits of the EMF Store. The JDT integration is currently under development. We are testing the integration with SVN and are further working on an integration with GIT. We plan to provide a release at the beginning of 2011. If you are interested in the functionality, feel free to contact us or leave a comment.

More seats for the Eclipse Demo Camp Munich (again :-)

2010-11-10T09:55:00.000-08:00

Due to overwhelming demand, we have extended the available seats for the November Demo Camp in Munich AGAIN :-)
and this time to to 100. Therefore we were able to include all people from the waiting list. There are a few seats left.
Please enter your name here to make sure you are in. Please also fill in this form, if you are attending.

Please fill in this form, if you have registered for the Democamp in Munich

2010-11-06T08:53:00.000-07:00

We are amazed by the interest in Munich's Democamp.
To handle the large number of attendees we kindly ask you to fill in this form, if you have registered for the Eclipse Democamp in munich.
If you have not registered yet, make sure to add your name to the waiting list. We are currently arranging for a bigger room, so hopefully we can include most of the people from the waiting list as well.

Plugin does not start

2010-10-20T01:15:00.000-07:00

This probably more a hint for Eclipse beginners:
Sometimes plugins do not start in your runtime environment, although they are included in your Run/Debug Configuration. Very often, the reason are missing required Bundles or violated constraints. To identify these issues, try to "validate Plug-ins" in the Debug or Run configuration (Menu "Run"):

This will show you a list of identitfied problems, which are often very easy to fix.

More seats for the Eclipse Demo Camp Munich

2010-10-19T02:31:00.000-07:00

Due to overwhelming demand, we have extended the available seats for the November Demo Camp in Munich to 70. Please enter your name here to make sure you are in.

Eclipse Demo Camp Munich

2010-10-12T00:56:00.000-07:00

We are happy to host a November Demo Camp in Munich this year on 23.11.2010, 17:30
For more information, please visit here
Please enter your name on the wiki if you plan to attend or give a talk.
See you there!
Jonas and Maximilian

EMF Client Platform goes RAP ...

2010-10-08T17:39:00.000-07:00

... EMF Transaction and EMF Validation as well!

We have shown a prototype of a EMF Client Platform RAP version here. The main remaining issue was although EMF has been offering a RAP version for quite a while, EMF Transaction and EMF Validation didn't (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=309927 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=309926).

We have had a loo at this issue in detail by checking out both projects. By reorganizing the dependencies as you usually do to use RAP, we could make both frameworks work on RAP:

RCP Version

RAP Version

It is amaizing that almost all of the existing features work out-of-the-box. We would be happy to contribute those changes to EMF Transaction and EMF Validation.

Announcement: Tutorials on Models

2010-09-30T03:10:00.000-07:00

We are happy to announce three tutorials taking place on Models 2010 in Osla next week:

Storing and Versioning EMF Models with EMFStore (quarter day 11:00‒12:30), Tuesday, October 5th

Building Model-Based Applications with the EMF Client Platform (quarter day 14:00‒15:30), Tuesday, October 5th

UNICASE ― Tooling for Software Engineering Models (quarter day 14:00‒15:30), Monday, October 4th

EMFStore Project approved

2010-09-01T05:55:00.000-07:00

We are happy to announce that the EMFStore project has been accepted as an Eclipse Project.
www.emfstore.org

EMF Client Platform project approved

2010-09-01T05:54:00.000-07:00

We are happy to announce that the EMF Client Platform project has been accepted as an Eclipse Project.
www.emfcp.org

The hottest Hot Key

2010-06-14T15:18:00.003-07:00

I was convinced that crtl+3 is the hottest hot key: quick access to everything!
Although it is quite slow :-(

The hottest Hot Key

2010-06-04T01:03:00.000-07:00

The "hottest" Hot Key is CRTL+SHIFT+L, showing all available Hot Keys ;-)

No more: "I have not installed this plugin"

2010-04-27T02:38:00.000-07:00

Announced at EclipseCon the beta test for Yoxos 5 is currently running. I havent used Yoxos so far, but the feature set is very promising for me. Furthermore it is free to use for open source or academic projects.
My use case is the following: I have many fulctuating developers in three different project settings. All of them need a running copy of the corresponding Eclipse IDE including plugins like subversion, checkstyle settings and of course the source projects. Especially for new an inexperienced developers it sometimes takes several hours until they have a working set-up. Additionally I wan to ensure everybody is working against the same configuration and plugin versions. NIGHTMARE!!
Yoxos allows to configure this centrally. Developers only get a .yoxos file referencing the online repository. On the first start of this file, all necessary plugins and configurations will be deployed automatically. And now the clue: If I change the configuration, e.g. updating a plugin to a new version, all developers get this update automatically. I think this can be very usefull for open source projects to lower the entry barrier for new developers.
Basically you can drag and drop every plugin you need into a configuration or use predefined profiles such as "Eclipse Modeling Tools":
Additionally you can configure seettings for the workspace such as Eclipse settings, source projects or Checkstyle:

Please note, that this is still the beta release of Yoxos, so please report any issues to yoxos5beta@eclipsesource.com
Also have a look at http://feedback.eclipsesource.com

EMF Client Platform on RAP

2010-04-21T02:16:00.000-07:00

Impressed by the RAP tutorial I wanted to finally try it out myself: Putting the EMF Client Platform (ECP) on RAP. The reason I did not try before was the missing support for EMF, which is available in Helios. Now EMF and EMF.edit is available for RAP. In this Post I describe how I transfered ECP to RAP, which issues occurred and how they can be solved (most of them). We are currently working on solving those to have a RAP version of ECP hopefully with the Helios release. If you already know how to install RAP and switch dependencies, please skip the first part. See the following screenshot of the RAP prototype showing an instance of the ECP navigator:

Preparation

Install Development Build Helios: Download for Mac OS
Install RAP 1.3 Tooling via Update Site: http://download.eclipse.org/rt/rap/1.3/tooling
After restarting Eclipse a new welcome screen appears, select "Rich Ajax Platform (RAP)" → "Install Target Platform", check the installation destination and installt the target platform. Make sure you set it as the default target.

Assembling the Target Platform

Select "Preferences" → "Plugin-Development" → "Target Platform" → "Rich Ajax Platform" → "Add" → "Current Target"
On the "Locations" tab select "Add" → "Software site" and add: http://download.eclipse.org/modeling/emf/emf/updates/2.6
Install the RAP plugins (listed below, also see screenshot):
Important: Make sure you uncheck "Include required software"

EMF RAP Common UI
EMF RAP Edit UI
EMF RAP - Eclipse Modeling Framework SDK for the Rich Ajax Platform
EMF RAP - Eclipse Modeling Framework Runtime for the Rich Ajax Platform

Select your newly assembled platform → "Apply" → "OK"

Regenerate Model

The first thing to do, is to re-generate your model. To re-generate a model, go to the project, that contains the model, select the subfolder "model" a double-click the file with the "genmodel" ending. An editor opens that show the root node of the model. Double-click this node and the properties editor open. Look for a section called "Editor". When you've found it, set the value of the attribute of "Rich Ajax Platform" to "true" (again, see screenshot for the attribute in question).

Now save the model and go back to the root node and right-click it. Select "Generate Model Code" and "Generate Edit Code".

Re-organize dependencies

Now I have to re-organized the following dependecies to add the RAP replacements. This can either be done by adding both versions (non-RAP and RAP) and set them to optional, or by imporing the packages.

non-RAP:

org.eclipse.ui
org.eclipse.ui.forms
org.eclipse.ui.ide
org.eclipse.jface.databinding
org.ecilpse.emf.edit.ui
org.eclispe.emf.transaciton.ui

RAP:

org.eclipse.rap.ui
org.eclipse.emf.rap.edit.ui
org.eclipse.rap.ui.views
org.eclipse.rap.ui.forms
org.eclipse.rap.jface

We won't deal with the remaining compilation errors for now (see the "Issues" list).

Create a RAP project

Follow these steps to create a RAP project with the navigator view enabled

Create a new plugin-project, call it org.unicase.rap.ui.example or something similiar.
Set the execution environment to be J2SE-1.5 and select "Yes" when asked for "Would you like to create a rich client application".
Replace dependency org.eclipse.ui with org.eclipse.rap.ui, add dependency org.unicase.ui.navigator.
Go to "Extensions" tab, select "Add" and add a new view via extension point "org.eclipse.ui.views".

Right click new extensions, select "New" → "View"
Select new view entry and set properities to be:

id: org.unicase.ui.navigator.viewer
name: Navigator
class: TreeView (via "Browse" button)

Save the plugin.xml
Switch to "Perspective.java" and add the following line in method createInitialLayout(IPageLayout layout).
layout.addView("org.unicase.ui.navigator.viewer",
IPageLayout.TOP,
1.0f, IPageLayout.ID_EDITOR_AREA);
Go to "Application.java" and delete the content of it. Change the parent to IEntryPoint.
The method that needs be implemented by Application looks like:
public int createUI() {
Display display = PlatformUI.createDisplay();
PlatformUI.createAndRunWorkbench( display,new ApplicationWorkbenchAdvisor());
return 0;
}
Go again to "Extensions" tab, remove "org.eclipse.core.runtime.applications" and add "org.eclipse.rap.ui.entrypoint". Set the class attribute to your Application.

Additionally note, that if you use IApplication, you can do it like this (copied from the RAP N&N):
With support for IApplications, you're now able to start a RAP application the same way as it is possible in RCP. This means that you don't need to provide an IEntryPoint implementation.

As stated in this example, the entrypoint parameter to access the application is equal to the id of the extension. This means the application is available at host:port/rap?startup=myapp. In case you want to refer to your application in the branding extension point (e.g. as default entrypoint), you have to use the fully-qualified name of the extension (e.g. org.eclipse.rap.demobundle.myapp).

Running ECP

Right-click your project, e.g. org.unicase.rap.ui.example and select "Debug As" → "Debug configurations". Create a new RAP configuration.
Set the entry point to the one you've created (Application)
Select the "Bundles" tab and click the button "Deselect all", click org.unicase.rap.ui.example and click "Add Required bundles". This will ensure that all necessary plugins are in place.
Also make sure that bundles "org.mortbary.jetty.server" and "org.eclipse.equinox.http.server" are also set as active. This is the actual web server you need to run RAP applications. Click again "Add Required Bundles" to be sure that the dependencies of these plugins are also satisfied.
"Debug".

Open Issues

The first and most important blocker is that org.eclispse.emf.transaction{.ui} and org.eclipse.emf.validation do not offer support for RAP. For ECP this is kind of blocker. I will file a bug report for those porjects and see what we can do about this. I have filed a bug report for transactions and validation to discuss this.
Use of IDialogConstants changed (see http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.technology.rap/msg04217.html)

Solution: Use IDialogConstants.get() instead of IDialogConstants directly, please see this bug

org.eclipse.swt.program.Program not available

Solution: We only use it for opening URLs. This can be better done with IDialogIWorkbenchBrowserSupport, see here

Composite#addPaintListener not available

Solution: Small Refactoring of two lines in ECP

Tooltip, DefaultToolTip not available

Solution: Use standard ToolTips

org.eclipse.ui.bindings not available

Solution: Ignore keybindings in RAP version

StyledText, StyleRange not available: https://bugs.eclipse.org/bugs/show_bug.cgi?id=277346

Solution: We have plans to replace that widget with a text field

No SWT.TRANSPARENT style bit

Solution: Composite#setBackgroundMode(SWT.INHERIT_FORCE)

No FileDialog

Solution: New Dialogs for RAP see https://bugs.eclipse.org/bugs/show_bug.cgi?id=300472

Conclusion
I am really convinced that it is possible to single source RCP applications with RAP. I recommend everybody, who have plans to single-source his application to just try it out. The target platform management and the available tutorials make this quite simple. The only thing not solvable in a couple of hours is the missing support for RAP of emf.tansactions and emf.validation. I hope it is possible to find a solution here.

Do we need yet another model repository? (BOF Wrap up)

2010-03-25T13:05:00.000-07:00

We had a pretty intense discussion Tuesday in the BOF "Do we need yet another model repository?". The good news is that we ended up drinking beer together with Eike at Hyatts bar :-)

It is pretty hard to warp up the discussions, because there were several topics and of course different opinions. A very important statement of the community was the need for transparency of the differences between EMFStore and CDO. As this was not covered so much in the BOF, I would also like to wrap that up from the viewpoint of EMFStore.
But first a few of the discussion topics:

Do we even need a model repository?
Surprisingly there was a discussion if we even need a model repository instead of just storing serialized EMF Objects in an SVN or CVS and using EMFCompare. Some people pointed out, that this solution does not scale very well to bigger models and involves frequent merging. Another alternative is to use XText, which provides a human readable format for EMF. This allows using SVN or CVS, but is usually focused on development models.

Slim vs. Feature Rich?
There was a quite philosophical discussion if a framework generally should provide as many features as possible or if it is desirable to have a framework, which exactly fulfils the requirements you need. The completely differing opinions were: First, a framework, which provides many features is desirable as it allows the user to choose what he will use now and leave room for what he might need in the future. Second, every feature, which the user does not use, is an “anti-feature” and potentially creates unnecessary complexity.

Developer Model vs. Application Model
There has been a discussion whether one or the other repository fits better to models used for development or to model used in an end-client application. Both repositories are currently used in both ways. More important are the underlying requirements, e.g. size of the model. In the end a developer model is an end-user tool for a developer.

Will another model repository confuse the community?
Definitely yes, if there is no transparency of the different features, focus and use cases when to apply one or the other. Although concurrent projects with a different focus provide user the opportunity to chose.

For this reason I would like to start with a description of the focus of EMFStore and the differences to CDO from my viewpoint. Of course even on a feature or technical level, this remains subjective.
EMFStore is focused on slim, but full vertical slice of a model repository application. While it provides everything from views down to storing models, it is focused on a selected number of features. To complete the vertical feature span, it also includes views to browse the repository and the local model workspace, to browse a model and its history and to configure access control on the server.

Offline
EMFStore is focused towards always-offline operation. It does only connect to the repository to commit or update a model, very similar to SVN or CVS. It allows obtaining a copy of the model from the repository in a certain version without locally cloning the whole repository. All changes applied to that model are then recorded locally and transferred after a commit to the central server.

Merging
To cope with conflicts that might occur after an extended offline period, EMFStore provides API and views for interactive merging. To deliver conflict detection and interactive merging EMFStore does not require diffing but directly operates on the recorded model changes, that are referred to as operations. Operations can also contain multiple model changes, which are handled as transactions during the merge. This allows for example to express model refactorings as an atomic unit for conflict detection and merging.

Model Migration
EMFStore provides integrated support for model migration tailored to the EMFStore persistency mechanism. That means whenever you change the meta-model of your application (i.e. the ecore) EMFStore provides support to migrate the existing instances of your model. The migration includes model in the client workspace and the server repository. Many operations such as adding attributes, references or classes are handled automatically. For other operations such as extracting classes in the model or moving attributes, migration code can be generated. Finally even for migrations, which are domain specific and not automatically resolvable there is framework support to write conversion code. This is based on the EDAPT framework.

Scale
EMFStore is focused on managing default EMF models without any additional modifications for scalability. This includes the limits of size of the model to fit into memory, which is basically the limit given by EMF. Cedric has mentioned as a guideline that this is about 1 million elements per gigabyte, but obviously this depends on the size of the single element.

Model Team Framework
The goal of the Model Team Framework is to provide a common API for model repositories. If both repositories implement this interface this would provide interoperability between both solutions.

As framework providers we will continue to communicate the differences between both framework to achieve transparency for framework users. Also we are happy to answer any request about this topic (helming@in.tum.de). See also emfstore.org

BOF-Session on EclipseCon: Do we need yet another model repository? EMFStore and CDO?

2010-03-23T10:28:00.000-07:00

BOF-Session on EclipseCon: Do we need yet another model repository? EMFStore and CDO?
We received a lot of questions about the differences between EMFStore and CDO and possible collaboration between both projects. I would like to announce that there will be a BOF 2day 19:15 about this topic at EclipseCon and invite you to join.

EMFStore in three steps

2010-03-14T16:06:00.000-07:00

EMFStore in three Steps

As a first component of the UNICASE project I would like to introduce the EMFStore (www.emfstore.org). The EMFStore is a model repository for instances of EMF models - very similar to SVN for source code. It supports features like commit, update and merging, but in contrast to SVN it operates on a model level and not on a textual level. The EMFStore can be used whenever a model instance of an application (e.g. data of a library) must be shared and collaboratively modified by different clients. The EMFStore is released under the EPL, we will propose it as a Eclipse project very soon.

I would like to show how to get started with the EMFStore as well as the basic features. On our homepage we promise that the EMFStore will run executing 3 steps. Since I don’t believe my colleagues, I will try this out myself. I use a fresh Eclipse Galileo Modeling Edition. I start with this video tutorial to install the latest EMFStore feature from this update site: http://unicase.googlecode.com/svn/updatesite/emfstoreNightly

The update site also includes the COPE feature providing support for model migration. It is now hosted as a Eclipse project EDAPT.

I create a run configuration for the emfstore server product and run it:

After successfully installing the EMFStore I shut it down again and continue with the next step to prepare my model. I followed this video tutorial. I have chosen to also use the library example from http://help.eclipse.org/galileo/topic/org.eclipse.emf.doc/tutorials/rosepkg/library.mdl. After downloading it, I create a new EMF project based on this model. Now I have to extend a common base class for any element I want to version with the EMFStore. This class is ModelElement from the metamodel. We should think about offering a dialog to add this base class to many elements in one step. Also I have to set “containment proxies” to true in the genModel. Now I could create my model and model.edit plugins.

Next step is to start the EMFStore including my new model described in this video tutorial. Very easy, very boring as I can only see some lines on the console. Therefore I continue to start the EMFStore client UI to create some model instances versioned on my EMFStore. First I start the EMFStore client as a plain RCP Application. I create a new EMFStore project using the EMFStore Browser

After checking out the project, I can directly browse it using the reflective navigator and editor. This allows me to create new elements of the library model, change their attributes and link them. We will describe those reflective tooling for EMF more in detail soon, but I will focus on the EMFStore.

Now I commit my changes by right clicking on the project. The commit dialog allows to have a detailed review of the changes I did in the project and adding a commit message.

I check out a second instance of the project to simulate a distributed project. I do some changes in the second checkout and commit the changes (changed the name of the author). They can now be applied to the first checkout by clicking on update (right-click on the project)

Now as a last step I want to provoke a merge, i.e. conflicting changes on both checkouts. I change the name of the writer in the first checkout and commit. Then I change it in the second instance before updating and try to commit as well. The system will ask me to update first and the present a model-based merge dialog.

Please note that the provided UI is meant as an initial tooling for the EMFStore. If you build applications based on the EMFStore you can customize and replace the UI with your own application. We will shortly describe how to do this.

If you are interested in news about the EMFStore, follow us on Twitter or contact us (helming@in.tum.de)

Also meet us at the BOF 2morrow evening 19:15 at EclipseCon and at our Poster on Wednesday Poster Reception.

UNICASE goes blogging

2010-03-12T07:17:00.001-08:00

Hello, this is the new blog of the UNICASE project. We will blogg about the Eclipse frameworks of the UNICASE project as well as about experiences with other frameworks and tools used by the UNICASE project. In this post we will introduce the different sub-projects of the UNICASE projects. Two of them will soon be proposed as Eclipse projects. The UNICASE project consist of three Eclipse based frameworks:

EMFStore

A model repository for EMF

Before you even start reading: Often a video says more than a thousand words, so if you prefer to let us explain to you what EMFStore is, watch this video.

EMFStore is a repository for EMF-based models. It started as part of a product (UNICASE client) but we have developed a framework from the initial code contribution. In contrast to existing solutions it supports an offline mode and is geared towards collaborative editing of the stored models. Therefore support for conflict detection and for merging models is built into the repository including versioning. EMFStore also ships with a set of client plugins containing a facade API for the server and more importantly views for commiting changes to, updating changes from the repository as well as merging models in a local workspace. In contrast to existing solutions the merging process is fully guided by a wizard and only shows conflicting changes to the model. In addition EMFStore provides access control on the repository and persistency for the models and their meta data on client and server side. EMFStore also supports changing the Ecore model of the stored EMF model instances by generating model migrators. This is a useful feature if your application evolves and requires changing your data model for example.

Features:

Model Repository (Server):

Versioning
Persistency
Access Control
Model Migration

Model Workspace (Client):

Model Change Tracking
Commit and Update Models
Offline Mode (No server connection neccessary)
Extensible Model Conflict Detection and Merging
Model Migration
Automatic client-side Persistence of Models
Views:

Commit/Update and Merge Views
Repository Browser to view all repositories and their models
History Browser to view the history of a model
Navigator showing local models
Reflective Editor showing model elements

To get started with EMFStore please goto the EMFStore Wiki.

EMFStore will be proposed as a Eclipse project in the next week.

EMF Client Platform (ECP)

The EMF Client Platform is a framework to build EMF-based client applications. The goal is to provide a one-click application based on a given EMF model. Besides the EMF model no additional components have to be developed or generated. Therefore ECP provides a standard solution including the most common features needed for EMF-based client applications. This application can then be customized step by step. This can be done by extending ECP or replacing single components completly.

Features:

Tree-based Navigator

Strutured creation dialog
Dynamic creation actions
EMF-based Drag and Drop Adapters

Editor for single EObjects

Reflective, no generation
Standard widgets for attributes and references
Single widgets replaceable

EMF-based Validation View

Affected EObject can be opened
Violations displayed in Editor
Model-based filters
Model-based refactorings

Workspace

Transparent Persistency
Versioning
Model Repository ((EMFStore))

Model-based GMF adapter to use GMF without files
Model Migration

ECP will be proposed as a Eclipse project in the next week. We are currently working on tutorials and a first release. Please contact us, if you are interested in trying out ECP

UNICASE client

UNICASE is a CASE-Tool integrating models from the different development acitivities, such as requirements, use cases, UML models, schedules, bug and feature models into a unified model. This unified model is highly traceable by design. The UNICASE client allows to view and edit these models in a textual, tabular and diagram visualization. The models are stored and versioned on a server comparable to svn but customized for models. Client and server are easily extensible to support integrating new models into the unified model. UNICASE is based on the Eclipse platform including EMF and GMF. It can also be used as a framework to build modeling applications that reuse its repository and visualization capabilities.

End User Features (click the link to see a screenshot of the feature):

Requirements Modeling
UML Modeling: Use Case, Class, State, Component, Communication Models
Integrated Project Management:

Task and Bug Tracking
Work Breakdown Structure
Iteration Planning
Project Status Visualization

Full-blown Vertical and Horizontal Traceability

You can find more information on UNICASE on our UNICASE website.