[galileo] Preparing Migration oaw4 –> oaw5 (PLE – featureconfig)

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 2  – you’ll find an overview of this blog series here.

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

Before migrating your projects its a good idea to make some preparations and refactorings. Thanks to Karsten Thoms Migration-Blog I noticed, that one feature of oaw4 isn’t migrated at the moment: org.openarchitectureware.util.featureconfig. This is used for PLE (Product Line Engineering).  In my projects I control execution of workflow components and cartridges using oaw – featureconfig. So I have to do some refactorings:

Inside my workflow I have to configure the features:

oaw4:

<workflow>
...
        <!-- 	Feature Configuration -->
        <component class="org.openarchitectureware.util.featureconfig.text.TextConfigurationReader">
	        <configFile value = "${generator.workflow}/features.txt"/>
        </component>
...
</workflow>

In this example the features are configured using a simple textfile “features.txt”:

oaw4:

...
+runMagicdrawExport
-skipUpToDate
+exportAlways
...

‘+’ means the feature is ON, ‘-‘ means the feature is OFF

In the example above: the Magicdraw Export should run and the Export should always be done – if changed or not.

Inside the workflow I can test if the feature is selected:

oaw4:

<workflow>
...
        <!-- 	run MagicDraw Export XMI into EMF ? -->
	<feature isSelected = "runMagicdrawExport">
		<cartridge file="${generator.workflow}/sub/export_workflow.oaw" inheritAll="true"/>
	</feature>
...
</workflow>

If the Feature “runMagicdrawExport” is selected the cartridge “export_workflow.oaw” is called. To make this run under oaw5 we can use Karstens workaround using properties.

oaw5:

<workflow>
...
        <!-- 	Feature Configuration -->
<property file ="${generator.workflow}/features.properties"/>
...
</workflow>

the file features.properties lookes like:

oaw5:

...
#MagicDraw Features
runMagicdrawExport=true
skipUpToDate=false
exportAlways=true
...

and inside the workflow we test if a feature is selected now using an if expression and properties:

oaw5:

<workflow>
...
        <!-- 	run MagicDraw Export XMI into EMF ? -->
	<if cond="${runMagicdrawExport}">
	 	<cartridge file="${generator.workflow}/sub/export_workflow.oaw" inheritAll="true"/>
	 </if>
...
</workflow>

Now FeatureSelect in workflow and cartridges runs well.
But (same as in Karsten’s project) inside my Xpand templates I’m using a function from Xtend extension to test if a feature is selected:
oaw4:

...
«EXTENSION org::openarchitectureware::util::featureconfig::features»
...
«DEFINE Xxxx FOR Yyyyy»
...
«IF isFeatureSelected("persistenceUnitHSQLDB")-»
        <!-- Creates an embedded HSQLDB database -->
        <hsqldb port="«getHsqldbPort()»" dbName="«getDatabaseName()»">
            <user name="easybeans" password="easybeans" />
        </hsqldb>
        <!-- Creates a JDBC pool with project-specific entity_data_source JNDI name -->
        <jdbcpool jndiName="«getDatabaseName()»_data_source_hsql" username="«getHsqldbUser()»"
            password="«getHsqldbPw()»"
            url="«getHsqldbUrl()»«getHsqldbPort()»/«getDatabaseName()»"
            driver="«getHsqldbDriver()»" />
«ENDIF-»
...
«ENDDEFINE»

To emulate isFeatureSelected() behavior I extended a global helper extension of my projects:

oaw5:

...
extension org::openarchitectureware::util::stdlib::properties;
...
Boolean isFeatureSelected (String feature) : getProperty(feature).trim()=="true";
...

Now in our Xpand template example above we can still use the isFeatureSelected() function – we only have to replace the …featureconfig::features extension with our own helper extension.
Note: All oaw5 code we have refactored here from our oaw4 code works in both environments and its a good idea to do this refactoring before moving your projects.
Please read also Karsten Thoms migration blog here.
more blogs will follow about oaw project migration to galileo. stay tuned…

9 responses

  1. I really appreciate your detailed migration story! There are surprisingly many migration stories already available, just 4 weeks after release. I guess you will blog about the MagicDraw adapter migration, too? Do you already have feedback from NoMagic?
    ~Karsten

    • yes, there will be info about MagicDraw adapter, … step-by-step –
      the migration isn’t the only work I’m doing ;-)
      and its much work refactoring PLE with some projects, some cartridges and 40+ features.
      btw: no response from NoMagic till now
      ekke

  2. Hi, I already made a study to compare Eclipse Xpand and Eclipse Acceleo, and I found Eclipse Acceleo better (simplier and better tooling.
    It there a plan for oaw5 to integrate Acceleo with other nice tools like MWE or xText?

  3. Xavier,
    you should ask this at the newsgroups.
    oAW5 is MWE + Xpand + Xtext.
    of course all is eclipse, all is modeling – its up to you to create other combinations of tools if this fits better to your needs.
    the oaw workinggroup is someting like glue to describe how MWE, Xpand and Xtext can work together and help oaw users.
    ekke

  4. Ueli,
    yes if cond = … works in 4.3.1, too.
    thats the reason why I have changed this in my oaw4 projects before moving to oaw5.
    then its easier to locate other errors / problems after moving to oaw5.
    thanks for making this clear – just re-read my post, perhaps misunderstanding that if cond = only works in oaw5.
    …was some work to change it all, but now it works same for me then featureconfig –
    and can be used in oaw4 and oaw5
    ekke

  5. Hi,
    at http://dslvariantmanagement.googlecode.com you can find ple-tooling for the new oAW5/TMF. Just checkout the sources via SVN from http://dslvariantmanagement.googlecode.com/svn/trunk/oAW5 (user: anonymous, read-only). An example demonstrates how to use the ple-tooling. To call the function isFeatureSelected() you just have to import the extension org::eclipse::xtext::var::featureaccess::ext::utils. It is similar to the old extension org::openarchitectureware::util::featureconfig::features.

    To run the example, first generate the language through the workflow GenerateAdsl.mwe in the plugin org.eclipse.xtext.demo.archdsl.language. Then you can generate the source code through the workflow genProductAPI.mwe in the project “test”. That’s it :-)

    PLE support in workflows is currently not supported. But so far you can use Karstens workaround with the if condition.

    For more details, see the documentation at http://dslvariantmanagement.googlecode.com/files/UsersGuide-0.6.pdf

    Cheers,
    Andy

  6. Andreas,
    thanks for your informations about the new dslvariantmanagement for oaw5/TMF.
    Great to see that work is going on :-)
    esp. in my projects (ERP solutions) with customers from different domains management of variants is important.
    At the moment my goal is to make my oaw4 projects run under oaw5 and Karstens workaround works well for this.
    Later I’ll take a look at your new variant management.
    ekke

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,118 other followers

%d bloggers like this: