Since build in DevOps Model RealTime is managed through the CDT (for details, see https://www.eclipse.org/cdt/ ) there are some differences in how build or makefile variables are supported. In the CDT, the makefile is generated and the assumed variables are defined through environment variables and/or path maps. RoseRT allows for makefile variables which are defined explicitly in the makefile fragments. These work fine for the compile and link because the make system resolves the variables. After migration to Model RealTime, this is still true, but the CDT can’t resolve them dynamically so warning and problem markers are created (indexing isn’t functional). To solve this problem, on import, all makefile variables are replaced with an Eclipse value variable. The problem with this is that it is a workspace variable and is not easily contributed to a CM system. The variables must be shared by exporting the variables through the Eclipse "File -> Export (preferences)".
Above is a RoseRT model with inclusion paths that assumes makefile variables are defined.
Instead of using makefile variables, use PathMaps or Environment variables to define variables instead. That way, there are no issues in a team environment after migration of the model since the PathMaps exist in the model and the environment variables aren’t tooling specific.
Code generation is a critical part of the RoseRT and Model RealTime tooling. Therefore, a lot of work has gone into making sure all aspects of code generation are semantically equal in both RoseRT and Model RealTime. The major difference is that Model RealTime code is generated into a CDT C++ project which is then compiled and built through the Eclipse build facility. Model RealTime supports C++ and C code generation, but not Java.
Since the code is generated into a CDT project, not all of the "C++ Generation" properties may be useful or relevant anymore. Any of the properties for specifying directories for code generation may not provide value after import. For instance, you can specify the "OutputDirectory" property for a component to be any directory in your file system. By default, it will output into your model directory. In RoseRT, it might be more useful to redirect this outside of your model directory especially if it conflicts with the CM system in place. In , the CDT project where the source is generated to is a peer to the model project in the workspace so this conflict won’t exist anymore. If you do specify and override this property, after migration, the CDT project still appears in the workspace, but it will have a location value to the overridden directory.
Scripting is a powerful way to query the model for custom information or extend the model capabilities of the tool. In Rational Rose RealTime (RoseRT), this is done through the RRTEI which has Summit Basic syntax with a rich set of commands and API. In Eclipse (Model RealTime), the extensibility is done in a completely different way with a Java-based technology integrating with the plug-in facility of OSGI. Consequently, it is not practical or feasible to provide a migration path for the RRTEI scripts. Any scripting in Rose RT must be rewritten using the new extensibility API of and all its underlying components. This should be considered in the case of a future migration to for any new scripting projects since the effort would have to duplicate in the new tooling. This is worth the effort in the long term since these extensions are built on open source components that are reused in many contexts. The expertise gained is re-applicable across most Eclipse applications that build on the same open source components.