[galileo] Convert Xpand/Xtend projects from oaw4

openArchitectureWare moved to Eclipse Modeling as part of Galileo release. This blog series reports my experiences to migrate a huge oaw4 project. This is part 6  – you’ll find an overview of this blog series here.

oaw4 means openArchitectureWare 4.3.1, oaw5 means MWE (EMFT) + Xpand (M2T) + Xtext (TMF) – more infos at oaw WorkingGroup.

If you followed this blog series – your installation of oaw5 is finished. Now lets start the conversion of your oaw4 projects. My blog only covers conversion of Xpand – Xtend projects, conversion of Xtext isn’t covered. You should take a look at Peter Friese’s blogs here and the Xtext documentation here.

Add Xpand/Xtend nature to oaw projects

Using oaw4 your openArchitectureWare projects has got a special “nature“.

Natures of a project are stored in .project files. You’ll found those files from Explorer or Finder directly below your project directory:

Hint: if you’re using OSX and don’t see the file – please read more about invisible system files on OSX at this page of my blog.

Opening the .project file, look at the natures section and delete the old oawNature:

<nature>org.openarchitectureware.base.oawNature</nature>

Its not really needed to delete it, but I recommend to do this – its always better to clean things up.

Now we have to add the new Nature – this is easy done: right-click on your oaw project and click

Your oaw5 projects now got the new nature and should look like similar to this:

	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.eclipse.pde.PluginNature</nature>
		<nature>org.eclipse.xtend.shared.ui.xtendXPandNature</nature>
	</natures>

Convert oaw Builder

Not only the nature was added – also the oaw Builder. Please look at your Project Properties:

The new Xtend/Xpand Builder was added from your action above (Add Xpand/Xtend Nature) – please remove the oawBuilder !

Configure oaw5 Project properties

Looking at your project properties you’ll also find the new Xtend/Xpand properties:

If you followed my instructions from last blog, you already configured Eclipse Preferences for Xtend/Xpand:

Normaly – without checking “Enable project specific settings” these settings should be used in your projects. But there’s a bug at the moment (Bugzilla 284019) – so please check “Enable project specific settings” and use the same values as in Eclipse Preferences.

Hint: If you only use EMF Metamodels then the defaults are ok – if you’re using any other combination of metamodels, you have to do the settings for each of your projects.

oaw5 Project dependencies (MANIFEST.MF)

The next step depends from your project – dependencies, but some things are common. Before converting Class – names we try to fix our Manifest files – this makes it easier in the next steps.

• Open all MANIFEST.MF with errors and correct them
  • remove all org.openarchitectureware – Dependencies from Required Bundles or Package-Imports
  • add required plug-ins:
    • org.eclipse.xpand
    • org.eclipse.xtend
    • org.eclipse.xtend.util.stdlib
    • org.eclipse.xtend.typesystem.emf
    • org.eclipse.xtend.typesystem.uml2 (if uml2 is used))
    • org.eclipse.xtend.typesystem.xsd (if xsd is used)
    • org.eclipse.emf.mwe.utils
    • org.eclipse.uml2.uml.ecore.importer
    • org.antlr.runtime
    • org.redview.model (needed in my projects to get packages from org.eclipse.emf.ecore.generated_package extension point)
    • org.redview.model.extensions.riena (see above)
  • add imported packages:
    • org.eclipse.jdt.core
    • org.eclipse.jface.text
    • org.eclipse.core.runtime
    • org.hybridlabs.source.formatter (if Hybridlabs 2.0.0 used to organize imports)
    • com.ibm.icu.text
    • com.nomagic.launcher (MagicDraw integration)
    • com.nomagic.magicdraw.oaw.eclipse.plugins.oaw (MagicDraw integration)
    • org.slf4j (or your logging bundles)

Hints:

• the example above is only one way HowTo manage the dependencies – it depends from your projects (and how you’re using required-bundle and import-package)
• the MagicDraw Integration is work-in-progress (as-is 2009-07-23) – I’m just testing an update from MagicDraw. In the meantime you have to export manually from MagicDraw instead of automatically done from mwe workflow. If the solution ios running I’ll let you know in the comments of this blog
• if you don’t use UML, you don’t need the uml2 – plug-ins
• if you don’t use redView (Riena EMF Dynamic Views) you dont need those required redview plug-ins

Convert own Java Classes extending / overwriting oaw4

Perhap you have extended or overwritten some oaw4 Classes, then we have to rename them.

There are different ways how to solve this – if you’re doing it the first time its a good idea to log your changes, because then its easier to repeat steps.

The very first time I prefer to hover over the Type and then copy / paste:

Thanks to Eclipse this is no so easy to resolve.

Also very helpful: CMD-SHIFT-T Open Type:

This View shows you also the bundle (plug-in) where this Type belongs to. But if you followed my advice above and configured the dependencies, then you should have the most needed plug-ins and you can use the Hover-Copy-Paste – its faster.

In most cases renaming of Classes and Interfaces and changing the Import statements is all you have to do.

If you have extended Classes like

• UML2Writer
• AbstractWorkflowComponent
• AbstractEMFWorkflowComponent

you have to change the Overwritten invoke() Methode – its now invokeInternal().

@Override
	public void invokeInternal(WorkflowContext ctx, ProgressMonitor monitor,
			Issues issues) {
		super.invokeInternal(ctx, monitor, issues);
		// your stuff
	}

I’ll log all Search / Replace I’m doing while migration. For your convienence in the summary of this blog series you’ll find a download link.

If this all is done you’re well prepared to the next step: Converting Workflows – I’ll explain this in my next blog entry of this series.