Eclipse Common Build Infrsatructure (CBI) Hudson Server: https://hudson.eclipse.org/hudson/

The reason for this, was a general infrastructure change on the environment. The default settings for jobs were switched to JDK 7 and Maven 3.1.0 which are not working fine with Tycho 0.19.0 / 0.18.0. In the threads referenced at the end of this post, some people talk about required changes in Hudson to support the new maven release. However, the CBI still stucks with an old version of the Hudson CI server (hopefully they will update soon).

To fix this issue for the EMF Feature Model project, we changed our Hudson build job’s configuration to explictly to use a JDK 6

Links for further information:

David Williams described a similar issue on the CBI Dev mailing list:
http://comments.gmane.org/gmane.comp.ide.eclipse.cbi.devel/981

Some further notice can be found in the eclipse hudson forum
http://www.eclipse.org/forums/index.php/t/521849/

When you take a look at your gen model in the tree editor view, which is still accessible by the generator tab of your gen model editor, you might notice, that the referenced meta model package does not have a link icon but a standard package icon. Compare the icon shown for ECore and shown for the Javaapplication package in the screenshot below.

To fix this issue, you should make right click on your gen model in the package explorer and choose reload…

In the wizard, we first select the ecore model importer. Clicking next might result in an error dialog because of the GenModel reference. This can be irgnored by clicking OK is fine. On the next wizard page, our own meta model ecore file should be presented as Model URI. Clicking Next will lead us to a wizard page that allows us to configure the rerefences to the external meta models.

On this page, we have to ensure the that the external meta models are selected in the lower area (Referenced gen models) and not in the upper area (Root packages).

Afterwards, we can confirm the page by clicking finish and our gen model should be fixed now.

Thanks to Michael Hauck for essentials hints when not to seeing the wood for the trees

The slides of this talk are available on the VSKI’s website: http://www.vksi.de/sneak-preview/11102012-qs-best-practices-in-karlsruhe.html

For example, extracting a OMG KDM model using the MoDisco Java Discoverer (http://wiki.eclipse.org/MoDisco/SimpleTransformationChain#Contextual_menu) results in a set of models representing your software artifacts of a JDT project:

The model file _java2kdm.xmi represents the starting point to enter the model. It contains only references to the other models containing different parts of the overall model.

To load a complete resource set you need to

1. load the required packages
2. register the xmi resource factory (if not registered by default in your environment)
3. create the resource set
4. load the resource
5. resolve all proxies

This can be done by he following code:


// load the required meta class packages
JavaapplicationPackage.eINSTANCE.eClass();
JavaPackage.eINSTANCE.eClass();

// load the resource and resolve the proxies
ResourceSet rs = new ResourceSetImpl();
Resource r = rs.createResource(URI.createFileURI(java2kdmModelFile.getAbsolutePath()));
r.load(null);
EcoreUtil.resolveAll(rs)


Now the model can be loaded and the references will be resolved. If you want to access the JavaApplicationModel you can access the first element of the resource and convert it:

// convert the model to a java model
EObject model = r.getContents().get(0);
if(!(model instanceof JavaApplication)){
throw new IllegalArgumentException("Model is not a JavaApplication: "+model.getClass().getName());
}
JavaApplication javaApplicationModel = (JavaApplication)model;

The code provided below manages to load a java / kdm model extracted by the MoDisco tooling. Note that the class KDMUtils has a method loadKDMModelFromDirectory() which requires the base path where all of your models are stored in (as shown in the picture above)

package org.splevo.diffing.kdm;

import java.io.File;
import java.io.IOException;

import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
import org.eclipse.emf.ecore.util.EcoreUtil;
import org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl;
import org.eclipse.gmt.modisco.java.emf.JavaPackage;
import org.eclipse.modisco.java.composition.javaapplication.JavaApplication;
import org.eclipse.modisco.java.composition.javaapplication.JavaapplicationPackage;

/**
 * The Class KDMUtils. Utility class to handle omg kdm models in general and
 * java specific extended models in specific.
 */
public class KDMUtil {

	  /**
	   * Load Java2KDM model from the standard java2kdm file set.
	   * 
	   * Based on a supplied main file loads the complete resource set, resolves all proxies 
	   * and returns the JavaApplication model.
	   * 
	   * Note that the method is limited to java specific application models because their is no
	   * other discoverer available at the moment.
	   * 
	   * @param java2kdmModelFile
	   *            The file object pointing to the main model file
	   * @return the loaded java application model
	   * @throws IOException
	   *             Identifies that the file could not be loaded
	   */
	  public static JavaApplication loadKDMModel(File java2kdmModelFile) throws IOException{

		// check that the file is accessible
		if (!java2kdmModelFile.canRead()) {
			throw new IOException("cannot read model file "+ java2kdmModelFile);
		}
	    
	    // load the required meta class packages
	    JavaapplicationPackage.eINSTANCE.eClass();
	    JavaPackage.eINSTANCE.eClass();

	    // register the factory to be able to read xmi files
	    Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap()
	    				.put(Resource.Factory.Registry.DEFAULT_EXTENSION,new XMIResourceFactoryImpl());
	    
	    // load the resource and resolve the proxies
	    ResourceSet rs = new ResourceSetImpl();
	    Resource r = rs.createResource(URI.createFileURI(java2kdmModelFile.getAbsolutePath()));
	    r.load(null);
	    EcoreUtil.resolveAll(rs);
	    
	    // convert the model to a java model
	    EObject model = r.getContents().get(0);
	    if(!(model instanceof JavaApplication)){
	      throw new IllegalArgumentException("Model is not a JavaApplication: "+model.getClass().getName());
	    }
		JavaApplication javaApplicationModel = (JavaApplication)model;
	    
	    return javaApplicationModel;
	  }
}

Both of these actions will open a dialog to select the resource you would like to reference. This dialog provides only file selections from your workspace or your filesystem. However, this is not sufficient, if you would like to reference a model which is included in a plugin, especially if the plugin is packaged within a jar. Furthermore, referencing a model relative to your file system or workspace would impede to share your model with others.

To solve this problem, you can type in an eclipse plugin uri directly in the the dialog’s text field. Such a URI has to follow the pattern platform:/plugin/[plugin-id]/[relative path in the plugin]

For example, if you would like to load the OMG kdm model provided by a modisco plugin, you would type in the url
platform:/plugin/org.eclipse.gmt.modisco.omg.kdm/model/kdm.ecore