OpenChrom 0.9.0 “Mattauch” GA

I proudly announce the official release of OpenChrom 0.9.0 “Mattauch”.
Some new data converters and a lot of improvements have been added. Stay tuned.
Moreover, use IdeaScale to submit new ideas.

Tell us your ideas and vote!

Images tell more than words!




Posted in Uncategorized | 2 Comments

Eclipse Science Working Group – press releases

Hi folks,

here’s a small selection of the latest press releases for the newcomer working group at the Eclipse Foundation:

New Global Collaboration for Scientific Software Announced by the Eclipse Foundation
Insight into the Eclipse Science Working Group

Startschuss für die Eclipse Science Working Group
Open Source und Wissenschaft sind ein Dream-Team

Posted in Uncategorized | Leave a comment

Eclipse Hackathon Hamburg, Germany

Finally, we’ve finished our first Eclipse Hackathon in Hamburg successfully.

Eclipse-Hackathon Hamburg

Eclipse-Hackathon Hamburg

Eclipse-Hackathon January, 2014

The next Eclipse Hackathon in Hamburg, Germany is scheduled for March, 2014:

Eclipse-Hackathon March, 2014 (scheduled)

Posted in Uncategorized | 1 Comment

How to handle preferences – consistently

Eclipse offers a great support to handle preferences.

Eclipse PreferencePage

Eclipse PreferencePage

Moreover, Eclipse 4 offers dependency injection for an even better handling, see

But could this functionality be improved? I think yes!

Imagine, you’d like to access the preferences from a model plug-in. I’m used to separate the model and user interface plug-ins. Hence, how could it be achieved to not mix up the Model and UI plug-in? Let me show you a simple solution how this issue can be solved.

net.openchrom.calculator (Model plug-in)
net.openchrom.calculator.ui (UI plug-in)

Everybody should be familiar with the decalaration of a preference page and its initializer in the UI plug-in. Once more, here are the extension points for the plugin.xml:

		name="My Preference Test">

The preference initializer is responsible to set the default values. Now we have to decide where to define the pereference constants and its default values. We don’t want to define the constants twice. This could be done in the model plug-in. It’s a big advantage to declare it in the model plug-in, cause it can be referenced by the UI plug-in without violating the separation of concerns. We use for example the class net.openchrom.calculator.preferences.PreferenceSupplier:

public class PreferenceSupplier {
	public static final String P_STRING = "string";
	public static final String DEF_STRING = "Hello World";
	public static final String P_BOOLEAN = "boolean";
	public static final boolean DEF_BOOLEAN = true;
	public static final String P_DOUBLE = "double";
	public static final double DEF_DOUBLE = 3.14159d;
	public static final String P_FLOAT = "float";
	public static final float DEF_FLOAT = 1.618f;
	public static final String P_INT = "int";
	public static final int DEF_INT = 42;
	public static final String P_LONG = "long";
	public static final long DEF_LONG = 23;

The string “P_*” is the preference constant and the “DEF_*” member is the default value for the aforementioned preference. As noted earlier, there is a preference initializer. Anyhow, we can’t move it to the model plug-in, cause it contains a reference to the class org.eclipse.jface.preference.IPreferenceStore which should be not part of the model (org.eclipse.jface is a UI plug-in). Hence, we have to find a way to satisfy the needs of the preference initializer dynamically. That’s why we add a static method to our PreferenceSupplier that returns a Map with the initialization entries.

public class PreferenceSupplier {
	public static Map<String, String> getInitializationEntries() {

		Map<String, String> entries = new HashMap<String, String>();
		entries.put(P_STRING, DEF_STRING);
		entries.put(P_BOOLEAN, Boolean.toString(DEF_BOOLEAN));
		entries.put(P_DOUBLE, Double.toString(DEF_DOUBLE));
		entries.put(P_FLOAT, Float.toString(DEF_FLOAT));
		entries.put(P_INT, Integer.toString(DEF_INT));
		entries.put(P_LONG, Long.toString(DEF_LONG));
		return entries;

This is an advantage, cause we are now able to control the entries to be initialized. We can go back the UI plug-in and have a look at the class net.openchrom.calculator.ui.preferences.PreferenceInitializer. The following code adds the values for us automatically:

public class PreferenceInitializer extends AbstractPreferenceInitializer {
	public void initializeDefaultPreferences() {

		IPreferenceStore store = Activator.getDefault().getPreferenceStore();
		Map<String, String> initializationEntries = PreferenceSupplier.getInitializationEntries();
		for(Map.Entry<String, String> entry : initializationEntries.entrySet()) {
			store.setDefault(entry.getKey(), entry.getValue());

As you can see, the IPreferenceStore instance is retrieved by calling the Activator. Normally, the Activator extends the AbstractUIPlugin class. In such case, everything is fine. Do we have a problem if the Activator only implements the interface BundleActivator? No, we don’t. We only have to add a method to return the preference store, which would result in the following call “Activator.getPreferenceStore();” to get the store. A new ScopedPreferenceStore will be created. But why do we import the scope context and the preference node from the PreferenceSupplier of our model class? It’s simple, because we have therewith control over the scope and can fetch preferences dynamically, as it will be shown later on.

public class PreferenceSupplier {
	public static final IScopeContext SCOPE_CONTEXT = InstanceScope.INSTANCE;
	public static final String PREFERENCE_NODE = "net.openchrom.calculator.ui";
public class Activator implements BundleActivator {

	private static BundleContext context;
	private static IPreferenceStore preferenceStore;
	public static IPreferenceStore getPreferenceStore() {

		if(preferenceStore == null) {
			preferenceStore = new ScopedPreferenceStore(PreferenceSupplier.SCOPE_CONTEXT, PreferenceSupplier.PREFERENCE_NODE);
		return preferenceStore;

Anyhow, we’re using the AbstractUIPlugin approach in this case, hence we don’t need the BundleActivator approach. The next class is the preference page of UI plug-in which needs to be edited. The field editors can be added as we think it’s the choice for the user:

public class PreferencePage extends FieldEditorPreferencePage implements IWorkbenchPreferencePage {

	public void createFieldEditors() {

		addField(new StringFieldEditor(PreferenceSupplier.P_STRING, "String", getFieldEditorParent()));
		addField(new BooleanFieldEditor(PreferenceSupplier.P_BOOLEAN, "Boolean", getFieldEditorParent()));
		addField(new DoubleFieldEditor(PreferenceSupplier.P_DOUBLE, "Double", getFieldEditorParent()));
		addField(new FloatFieldEditor(PreferenceSupplier.P_FLOAT, "Float", getFieldEditorParent()));
		addField(new IntegerFieldEditor(PreferenceSupplier.P_INT, "Integer", getFieldEditorParent()));
		addField(new LongFieldEditor(PreferenceSupplier.P_LONG, "Long", getFieldEditorParent()));

	public void init(IWorkbench workbench) {


Last but not least, we’d like to access the preference values from our model plug-in. Therefore, we add a convenient method to the PreferenceSupplier class to get the IEclipsePreferences instance:

public class PreferenceSupplier {
	public static IEclipsePreferences getPreferences() {


That’s it. We can now access each preference in our model and UI plug-in by make a simple call:

IEclipsePreferences preferences = PreferenceSupplier.getPreferences();
int theAnswerToTheQuestionOfAllQuestions = preferences.getInt(PreferenceSupplier.P_INT, PreferenceSupplier.DEF_INT);

Easy, isn’t it?

Posted in Uncategorized | 2 Comments

Migration to e4 – OpenChrom® 0.8.0 has been released

I proudly announce the release of OpenChrom® 0.8.0 “Dempster”!
OpenChrom has been migrated to the Eclipse e4 application platform. It is based on the latest release Eclipse 4.3 “Kepler” now.

OpenChrom 0.8.0 "Dempster"

Finally, many thanks to Lars Vogel and Markus Kuppe from the vogella GmbH. They were a great help in solving some tricky problems.


Posted in Uncategorized | 4 Comments

Can’t find IDfind.ext exception

Whilst migrating OpenChrom to the new Eclipse e4 application platform, I’ve encountered an exception, which was hard to resolve. All 3.x editors couldn’t be opened within the first try, curiously. Instead, an error was displayed:

Editor 3.x - e4

An exception

org.eclipse.e4.core.di.InjectionException: java.lang.IllegalArgumentException: can’t find IDfind.ext

was thrown. Finally, I’ve found a solution how to handle this issue. It works fine now, after adding the workbench action constant in the class.

protected void fillMenuBar(IMenuManager menuBar) {
	MenuManager editMenu = new MenuManager("&Edit", IWorkbenchActionConstants.M_EDIT);
	editMenu.add(new GroupMarker(IWorkbenchActionConstants.FIND_EXT));


Posted in Uncategorized | 2 Comments

Cool Eclipse Kids trink Cola. Cool Eclipse Adults enjoy Coffee …

I read Lars post about building Eclipse 4.2 via Maven/Tycho from the command line this morning:

Honestly, I didn’t thought it will work. But it did! Cool stuff!

Ubuntu Linux 12.04 LTS
java version “1.7.0_09″
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Default locale: de_DE, platform encoding: UTF-8
OS name: “linux”, version: “3.2.0-34-generic”, arch: “amd64″, family: “unix”


Eclipse CBI is definitively worth a try!

Posted in Uncategorized | Leave a comment