I’m happy to present the agenda of talks:

1. Executable Specifications for Xtext Languages by Moritz Eysholdt

2. Building a tool based on EMF in 20 minutes by Eugen Neufeld

3. Introducing Eclipse Sirius by Cédric Brun

In this year’s format each presenter will have 20 minutes. I’m looking forward to this event and interesting discussions afterwards. Hope to see you there!

Please follow this link to get to the tutorial:

http://eclipsesource.com/blogs/tutorials/q7-basic-tutorial/

Additionally, bundles that define an API are required to maintain compatibility until the next major release. Therefore users of a framework can expect that bundles do not break their API until the major version increases, e.g. from 1.x to 2.x. Between major releases, the API is allowed to be extended if the minor version is increased, e.g. from 1.1 to 1.2.

While it is very obvious that these rules make sense for open source frameworks that are used by hundreds of projects, even in a medium-sized inhouse project, it is often useful to follow these guidelines to coordinate different teams and components. However, the best rules are worthless if there isn’t good tooling to enforce them.

Fortunately, the Plug-in Development Environment (PDE) has provided the API Tooling for quite some time. It allows the tracking of changes to a bundle defining an API. Whenever the API is changed, it provides errors until the bundle is configured according to the above mentioned rules. This means that in case of additions to the API, they need to be annotated with an @Since tag and the minor version number needs to be increased. If there is a breaking change to the API, the major version number of the bundle needs to be increased. Additionally the API tooling provides annotations that allows additional restrictions on the usage of the API. For example these annotations can define an interface not to be implemented by clients.

API Compatibility Check

Enabling these checks on a bundle is actually pretty simple and requires only two steps. The first one is to define a base line. That is, the last release of a bundle or a group of bundles. The API tools will compare the current state of the bundle in your workspace with this baseline to determine if there are API changes. The base line needs to be configured within the developer’s workspace. Under Preferences => Plug-In Development => API Baselines, you can add folders which contain the binaries of the releases you want your bundles to be compared with.

Once the base line is set, you can enable the API Tools for a specific plug-in with a right click on the plug-in and selecting Plug-in Tools => API Tools Setup. This will add an API Tools nature to the project and enable the API check.

Now if you change parts of the API, the tooling will provide errors. In the following example, a new method is added to an interface which is part of the API of a bundle. The last release of the bundle was version 1.0.0. In this case, the API tooling will show two errors. Additions to the API, e.g. new methods in an interface, must be marked with a @Since annotation, specifying since which version the additions are available.Therefore, the first error indicates, that the new method must be marked with a @Since annotation. The second one indicates that the minor version of the bundle needs to be increased as new API has been added:

The second error should be fixed first by increasing the version number. After that, the @Since annotation can be added using a quickfix. If you add the @Since tag first, it will automatically add the current version (1.0.0) of the bundle which, in this case, is the wrong one. This will result in another error saying that the since tag is invalid.

API Restrictions

The API tooling defines several annotations which restrict the use of interfaces and classes which are part of the API. All annotations are placed in front of the restricted element as part of the Javadoc, e.g.:

Depending on the IDE settings of an API user, violations of the restrictions will cause errors, warnings or will be ignored. The following annotations are supported:

• @noimplement: Clients are not allowed to implement an interface
• @noextend: Clients are not allowed to extend a class or interface
• @noinstanciate: Clients are not allowed to instantiate a class
• @nooverride: Clients are not allowed to override a method
• @noreference: Clients are not allowed to reference a method, a constructor or a non-final field.

If you are interested in giving a talk, please send a short description (a few sentences) to jhelming@eclipsesource.com. Depending on the number, we might have to select among the submissions.Submission Deadline is February 10th. Acceptance notification is February 20th.

Please adhere to the following guidelines:

• Topics presented in other sessions during the conference should only be proposed as teasers.
• Please provide sufficient context. Talks should start with a concise overview of what the presenter plans to demonstrate, or what a certain framework offers.  Even more important, explain how and why the topic is relevant.
• Don’t bore us! Get to the point quickly.  You don’t have to use all your allocated time. An interesting 3 minute talk will have a bigger impact than a boring 10 minute talk. We encourage you to plan for a 5 minute talk, leaving room for 5 minutes of discussion.
• Keep it short and sweet, and focus on the most important aspects. A conference offers the advantage of getting in contact with people who are interested in your work. So consider the talk more as a teaser to prompt follow-up conversations than a forum to demonstrate or discuss technical details in depth.
• A demo is worth a thousand slides. We prefer to see how your stuff works rather than be told about how it works with illustrative slides.  Please restrict the slides to  summarize your introduction or conclusion.

Looking forward to your submissions!

http://eclipsesource.com/blogs/tutorials/egit-tutorial/

http://www.eclipsecon.org/2013/sessions/eclipse-4-why-when-and-how-migrate

However, there is one pattern, which IMHO every project should consider applying – even if no migration to e4 is planned. I think it adds more flexibility and makes components easier to re-use and test. The basic idea is to separate workbench specific parts from parts that can be POJOs – eg. custom implementations and components implementing interfaces such as IViewPart. This is a very fundamental pattern in e4, but can actually be used in 3.x, too. Many projects have been applying this for years. Using the 3.x bridge provided by the e4 tools (developed by Tom Schindl), custom POJO implementations can even use dependency injection. However, even without this bridge, you’ll see that the separation still makes sense.

I’ve received many requests to document this pattern in more in detail so I’ve created a new tutorial as an appendix to our Eclipse 4 tutorial.:

http://eclipsesource.com/blogs/tutorials/eclipse-4-e4-tutorial-soft-migration-from-3-x-to-eclipse-4-e4/

Of course, I also tried Gource with projects I am involved in. The following video shows the history of the EMF Client Platform (1.0 branch). While Eike was configuring our build, I was working on the EMFStore integration. Like a video player, Gource also allows you to skip to a certain point in time. In the video, I jump to the time when Eugen joined the project. Later you see Florian starting the development of a UI model.

Due to renovations we can only offer 80 seats this time, so please make sure you register soon, as we usually receive more then 120 registrations. You can register on http://www.eventbrite.de/event/3972064552. You’ll also find detailed information about the location and time under this link.

We are looking forward to great demos! This is our preliminary agenda:

• Tom Schindl – e(fx)clipse – building cool UIs with Eclipse and JavaFX
• Ekke – A mobile App in 15 Minutes: Eclipse Momentics IDE with Cascades Builder: no slides, pure coding
• Jonas Helming – Migrating to e4
• Sebastian Benz – Jnario – executables Specifications for Java
• Andreas Graf – Developing an Autosar Editor with Graphiti – Lessons Learned.
• Maximilian Koegel – Fuzzy Testing
• Kai Tödter – LifeCycle Hooks and CSS-styled Login

The Munich DemoCamp will be sponsored by:

• EclipseSource
• Siemens

..and organized with a little help from Ekke