Palladio to Eclipse Indigo Migration

Introduction

Up to now (2011), the Palladio tool is coupled with the Eclipse Galileo Release (3.5). In the summer of 2011, Eclipse has published the Indigo release (3.7). As in the Helios Release (3.6) before, several enhancments also in the area of MDSD are included.

To keep up on speed with the state-of-the-art capabilities, it is our plan to upgrade the Palladio tooling to the new Indigo release.

The purpose of this wiki page is to document the migration process, pros and cons, as well as possible obstacles.

Info about Palladio Components and Dependencies

In this section we collect information about the migration of the core components, respectively the more general components we build on (e.g., the WorkflowEngine). Information about 3rd party components should be documented in the section of the Palladio component that contains the dependency or in the general section further down on this wiki page.

Core Components

Build

Needs updated build Eclipse. Issues with an updated pluginbuilder script have to be expected

• I have a build running on our build server. As the original build is not doing any tests at the moment, here some information, how to fix it.

1. Fist the eclipse extension dir in run-test.properties has to end in the eclipse dir (this seems to be a bug in the pluginbuilder scripts).
2. Second, for coverage runs, emma.jar needs to be on all classpaths. This can be achieved by putting it into the JAVA_HOME/lib/ext dir on the build server. Sadly, it still fails on the i43pc76 machine, but works on my local machine. Hence, I deactivated test coverage at the moment... Update: I found out how to do it (add emma.jar to the bootclasspath) However, this triggers the next bug in emma. A solution is to exclude all ANTLR generated files from the instrumentation as the long static string in this code do not work with emma. After excluding these files, all works nice as charm.

• Also the eclipse build host, needed manual adjustments. I installed dependent features using the P2 director command line application, as the old strategy of using DROPS is not any longer working as expected.

Command line is

./eclipse  -application org.eclipse.equinox.p2.director -r http://download.eclipse.org/releases/indigo/ -installIU org.eclipse.xtend.feature.group

in the directory of the eclipse installation used to build. Note, that DISPLAY needs to be set the :99 (our fake XServer) to prevent gtk issues. I strongly recommend to split the build into more builds. The large build at the moment is almost not maintainable. And why are there features in it like DSE? They should be put into separate feature builds.

Completions

Completions bring a dependency to mediniQVT, which has not been migrated to Indigo yet. However, there are no strong version dependencies to Helios; all versioned dependencies are "greaterOrEqual". This includes (for QVT Cockpit only, no examples included)

• plugin="org.eclipse.core.commands" version="3.5.0" match="greaterOrEqual"
• plugin="org.eclipse.core.expressions" version="3.4.100" match="greaterOrEqual"
• plugin="org.eclipse.core.resources" version="3.4.1" match="greaterOrEqual"
• plugin="org.eclipse.ui.forms" version="3.3.101" match="greaterOrEqual"

The QVT-R Examples cannot be installed in Indigo due to a dependency to plugin org.eclipse.emf.ocl which is deprecated.

Assuming that the rest of the dependencies are accurate, the 3.6 update site can be used to install mediniQVT-R in an Indigo MDT installation (tried installing, didn't try executing). -Martin

I am able to compile all required plugins under Eclipse 3.7, but I have not tested executing them either. -Steffen

I was able to execute several QVTr scripts under Indigo without issues. The «Examples» feature didn't install, this didn't pose a problem though. - Andreas

Editors

Editors can compile (ANTLR issue needs to be resolved). However, at runtime not all editors work as expected, e.g., System editor has no connectors.

• Update: I cannot reproduce the editor issue. At the moment everything seems to be working...

MetaModels

Metamodels seem to work. Tested serialiser, modelling and OCL validation. However, I did not regenerate them using Eclipse 3.7 EMF code gen.

ProbFunction

Works with slight adaptations wrt. ANTLR. However, these should have been already included for the Eclipse 3.5 release as current setup is outdated Update: ANTLR issue' solution is backported and resolved - also for Eclipse 3.5.

ProbeSpecification

Compiles and works in SimuCom together with SensorFramework. I have not tested EDP2 as I do not know where the sources are ;-)

SensorFramework

Needs a minor patch as a wizard is using Eclipse internal API (maybe a bad idea anyhow). Patch is in SVN in PCMIndigoMigration

R Visualization works on Windows 7. To be tested on a Mac.

SimuCom

After some still minor adjustments I was able to execute SimuCom under Eclipse 3.7 and display results. This is at least good news :-)

Solver

Does not compile as it uses old OCL API. Needs little effort for migration. Not compilable code is nicely encapsulated in a helper class.

• Update: OCL issues are resolved even for Eclipse 3.5

Statistics

Compiles. I do not expect Eclipse 3.7 specific issues

StoEx

Works with slight adaptations wrt. ANTLR. However, these should have been already included for the Eclipse 3.5 release as current setup is outdated

• Update: ANTLR issue' solution is backported and resolved - also for Eclipse 3.5.
• 2. Update: The ANTLR issue is tough. The problem is that xtext is used for MWE and needs antlr 3.0 but does not declare a maximum version (as it is also normal). So a real fix is only available for Eclipse 3.7 where all plugins can run with ANTLR 3.2. I am using antlr 3.0 in our own compiled version now again in our 3.5 build.

Workflow

Compiles and works with my tests on SimuCom.

Common Components

WorkflowEngine

WF Engine is working with slight adaptations. QVT-o Job becomes much cleaner with Indigo, QVT-r is not working (means I have not tried to migrate mediniQVT to Eclipse 3.7)

PROs and CONs

Pro:

• Can use up to date Eclipse (always good), runs more stable on MacOS
• Can use up to date Xtend (successor of Xpand). Allows to write much cleaner M2T transformations
• Could allow to replace all StoEx stuff with a clean xtext and xbase editor
• Is required to integrate third-party tools like TGG engine, Reclipse or Story Diagrams (all UPB tools, run under Eclipse 3.6 at the moment)
• Resolves the never ending ANTLR issue

Cons:

• All need to test their plugins a bit
• QVT-r support is still an open question
• Might also impact dependant tools like Q-ImPrESS, etc. However, they can still rely on PCM 3.2 under Eclipse 3.5