oAW 4 migration with cartridge adaption

In one of my projects we make use of the Fornax oAW 4 cartridges Hibernate and JavaBasic. This week we migrated our generator projects to Eclipse Galileo (we use the EPP Modeling Package at the moment) with MWE, M2T Xpand and TMF Xtext. (Note: I’ll name this package here oAW 5 although it does not exist yet, but this is another topic).

Now these cartridges are not available for oAW 5 yet and will not in the near future. So we have these alternatives:

• migrate the cartridges
• replace the cartridges by a equivalent, project specific cartridge which takes the same input and produces the same output
• adapt the cartridges and leave them as is

We decided to try adapting it. Now the problem is that the cartridges are oAW 4 specific and won’t work without changes. We faced some problems, and luckily we were able to solve them. Some are quite hacks 😉

Dependencies

The required plugins have changed. With oAW 4.3.1 only the aggregator plugin org.openarchitectureware.dependencies and org.openarchitectureware.uml2.adapter were required dependencies. In our generator project we now have these dependencies (besides project specific ones):
org.eclipse.xtend.typesystem.uml2;bundle-version="0.7.0",
org.eclipse.xtend.util.stdlib;bundle-version="0.7.0",
org.eclipse.xpand;bundle-version="0.7.0",
org.eclipse.xtend;bundle-version="0.7.0",
org.eclipse.jface.text;bundle-version="3.5.0",
org.eclipse.xtend.typesystem.emf;bundle-version="0.7.0",
org.eclipse.core.runtime;bundle-version="3.5.0",
org.eclipse.jdt.core;bundle-version="3.5.0"


Workflow

The standard workflow is packaged into the cartridge jars and cannot be changed. The namespaces of the used components has changed. Looking up the component class names with CTRL+SHIFT+T (Open Type) quickly revealed the package names the workflow components have now.

Configuration of the components did not change.

Tipp: if you want to know which workflow component are available then open the interface org.eclipse.emf.mwe.WorkflowComponent and press F4. This opens the type hierarchy and allows you to browse and inspect all known WorkflowComponent implementations. The most interesting ones are derived from AbstractWorkflowComponent2.

Loading profiles

Formerly profiles were just located by classpath. We had the Persistence.profile.uml in folder model, which was on classpath root. This profile could not be loaded anymore. The path was changed to a platform resource URI (platform:/resource/PROJECT/model/Persistence.profile.uml).

With the UML profile file from Fornax we had the problem that when instantiating the ProfileMetaModel instance with that file our generator process hang. It turned out that it was tried to open a HTTP connection to load “http://www.eclipse.org/uml2/2.1.0/UML“, which is declared as xmlns:uml in the model file. Eclipse did not have a internet connection nor should it require. The profile was loaded in MagicDraw 16 and reexported, and the file changed to xmlns:uml="http://www.eclipse.org/uml2/2.0.0/UML". After doing so the profile could be loaded with ProfileMetaModel. Since we use Galileo, the installed UML2 plugins have version 3.0.0.

Stdlib Extensions

The cartridges make use of the oAW’s stdlib extensions. The extensions exist unchanged, but now can be found in the plugin org.eclipse.xtend.util.stdlib with the same package name. So the namespace of those extensions changed and workflow execution failed as follows:


ERROR - [ERROR]: Unable to load extension file : org::openarchitectureware::util::stdlib::io(Element: EvaluationException : Unable to load extension file : org::openarchitectureware::util::stdlib::io
org::fornax::cartridges::uml2::hibernate::checks::CartridgeProperties.chk[967,28] on line 27 'getHibernatePropertiesFile()'
; Reported by: -UNKNOWN-)
EvaluationException : Unable to load extension file : org::openarchitectureware::util::stdlib::io
org::fornax::cartridges::uml2::hibernate::checks::CartridgeProperties.chk[967,28] on line 27 'getHibernatePropertiesFile()'
at org.eclipse.internal.xtend.expression.ast.Expression.evaluate(Expression.java:56)

To solve this we added extension files with the same name as the old stdlib file and same package, and just reexport the new stdlib extensions. For example, for the IO extensions a file org/openarchitectureware/util/stdlib/io.ext was created with the following content:

extension org::eclipse::xtend::util::stdlib::io reexport;

Dieter Moroff had already the idea to provide a stdlib compatibility package that contain all oAW 4 stdlib extensions mapped this way. I think it would be great for all users to have that, it would make migrations more smooth. Maybe I find some time to realize it. Main question would be where to host this plugin. I think the sources should be kept at Sourceforge in the oAW 4 repository, and the plugin should be available through an update site on openArchitectureWare.org.

In our own templates that we have under development we just replaced the usage of org::openarchitectureware::util::stdlib... by org::eclipse::xtend::util::stdlib...

PLE feature

The cartridges make use of the org.openarchitectureware.util.featureconfig plugin, which has not been migrated yet. We had to replace the behavior. The cartridges use this plugin mainly to conditionally execute workflow components. Since we had to replace the workflow files anyway we changed all <feature isSelected="FEATURENAME">...</feature> occurances by <if cond="${FEATURENAME}">...</if>, which has the same behavior, but configuration of the features is done by workflow properties and <if> is a built-in feature of the workflow engine. The if-components were not documented in the MWE reference yet, so we filed a bug which already has been fixed now.
The cartridge makes also use of the features.ext extensions, which defines a function isFeatureSelected(). We replaced the behavior by using the stdlib properties extensions. Therefore we configured our features in a properties file and read them with the PropertiesReader component.
<component>
<propertiesFile value="featureconfig.properties"/>
</component>

We created a file org/openarchitectureware/util/featureconfig/features.ext:

extension org::eclipse::xtend::util::stdlib::properties;

Boolean isFeatureSelected (String feature) : getProperty(feature).trim()=="true";

Changed namespace of internal types

oAW has a built-in typesystem (with types Type, Operation etc.) whose types were in oAW 4 in the namespace oaw. So if you have the expression uml::Class.metaType.name the result would be oaw::Type. With Eclipse M2T the namespace of those types changed to xpand2, so oaw::Type is now xpand2::Type. Normally you don’t work with the internal types directly until you do some reflection stuff, but extensions in the Fornax JavaBasic cartridge make use of those types. This leads to errors like this already when an extension is loaded and analyzed:

ERROR - Error in Component hibernateCartridge_transformations of type org.eclipse.xtend.XtendComponent:
EvaluationException : Couldn't resolve type for 'oaw::Type'. Did you forget to configure the corresponding metamodel?
org::fornax::cartridges::uml2::javabasic::extensions::DataType.ext[5047,76] on line 135 'boolean typeOf(uml::Type type1,oaw::Type type2)'
nofile[0,26] on line 1 'createDefaultValues(model)'

ERROR – Workflow interrupted. Reason: Couldn’t resolve type for ‘oaw::Type’. Did you forget to configure the corresponding metamodel?

To work around this the extension files need to be replaced. Since they are packaged in a jar it is required to copy them and make them available through the classpath before the cartridge. We use the approach to have a compatibility plugin which contains this .ext file as well as the stdlib compatibility extensions.

Problems with UML2 typesystem

We experienced some severe problems with the org.eclipse.xtend.typesystem.uml2 plugin that lead to EvaluationExceptions through our generator process. Basically the plugin is just a migrated version of the org.openarchitectureware.uml2.adapter plugin, but the behavior of the underlying EMF typesystem changed slightly but significant. It was not possible to handle different typesystems at the same time it (e.g. for M2M transformation), which blocked us. We opened Bug#283469 and hunted it down. Some other issues with the typesystem were detected and fixed. A patched plugin you can download from here. We created a folder dropins/oaw5-patch/plugins and put it there until the official service release will be available.
As a positive side effect it is not necessary anymore to register an UML2MetaModel nor EmfRegistryMetaModel instance in the workflow when a ProfileMetaModel is used, since it will delegate to them internally.

Hybridlabs Beautifier

The cartridges make use of the Hybridlabs Beautifier 1.1.9, which is only compatible with oAW 4. The new version 2.0.0 is now able to work also with M2T Xpand.

Conclusion

Our projects including cartridge adaption and bugfixing were migrated in about 4 days. The scenario is a real-world case, and some issues (esp. the mentioned bugs) we faced required deep knowledge about the implementation. I think most projects can be migrated even easier now, but if you face problems it might be worth ordering expert help before spending too much time. Experienced users of oAW 4 will not have much problems migrating the Xpand based code generators.

Advertisement