Developer's HOWTOs

How to create a trex.product file which is platform independent?

Install the Eclipse RCP delta pack which is available in the RCP SDK section on the download page of your Eclipse version. In the Overview tab for the trex.product file, select This product configuration is based on: plug-ins and in the Configuration tab, press Add Required Plug-ins. (Without the delta pack, only the plug-ins for your plattform will be added, with delta pack also the ones for other operating systems.) See also the RCP FAQ.

Whenever you apply changes to trex.product (not only related to the Configuration tab, but also in all other tabs), you must have the RCP delta pack installed''' Otherwise you will create a trex.product file which is not platform independent, i.e. running TRex as product on other platforms will fail! (Running as non-product, which is usually the case when TRex is installed via the update site, still works though.)

Finally, do not forget to copy the changes applied to trex.product also to plugin.xml by selecting Synchronize in the Overview tab of the product editor.

How to release a new release of TRex?

Once all open issues for the roadmap of a release are closed, a new TRex release can be released:

1. Run automated tests. (If fails: file new bug and delay release!)
2. Tag release in SVN.
3. If the release is supposed to be a stable release which should not get any new features, but bugfixes, a branch can be created. However, due to the short development cycles, this is currently not necessary.
4. Start automated build. (If fails: file new bug, delete tag in SVN and delay release!)
   1. To create the automated build, open an SSH connection to the TRex server
   2. In /var/lib/trex-builds, two directories are relevant: releases and releases-product. The first directory contains the configuration for the Eclipse plug-in release builds and the second directory contains the configuration for the TRex standalone version (Eclipse RCP Product).
      • If you want to create a new configuration directory from scratch, make a checkout of the trex.build directory into the /var/lib/trex-builds directory.
      • Depending on what kind of build you want to do (nightly plug-in build, product release build, nightly product build), copy the the corresponding customtargets*.xml to customTargets.xml.
      • Do the same for the build.properties and build.xml files.
   3. Each directory contains directories according to the version number.
   4. Copy the directory describing the last release and name it after the pending release.
   5. Make sure that the files are corresponding to the versions found in the .build plugin in the TRex repository tag.
   6. Make sure that the Eclipse base version in the base directory is up-to-date and contains the RCP delta pack.
   7. Adjust the build.properties file according to the new directories. Make sure that the pde build directory corresponds to the base target and adjust the version number and directories if necessary.
   8. Run ant in each configuration directory of the pending release.
5. Update release update site (/var/www/update) and zip-file (/var/www/releases) with files from automated build. The update site should be updated automatically from the ant scripts.
6. Mark as released in JIRA and create additional future release in JIRA roadmap.
7. Update Wiki download page. Announce on Wiki start page and on trex-announce mailinglist. Link to JIRA-created release notes from Wiki as changelog page.
8. Adjust version number in feature.xml in de.ugoe.cs.swe.trex and all plugin.xml to the next version according to JIRA roadmap and add .qualifier to version number. Commit.
9. Adjust version constraints in the TRex plug-ins. Version constraints are currently implemented in the TRex feature (de.ugoe.cs.swe.trex) and the ui (de.ugoe.cs.swe.trex.ui) plug-in.
10. Update TRex release on the following sites:
    • Freshmeat
    • EPIC
    • Eclipse Plugins
    • Eclipse Magazin
11. Celebrate!!!

How to make changes to the build system and to build.properties in particular ?

As you see in the above How to release a new release of TRex?, the file build.properties used at the TRex server for creating the nightly and release build is usually not taken from SVN trunk, but from a previous version. Hence, take care to instruct the maintainers to apply your changes to that file also to the automatic build system running on www.trex.informatik.uni-goettingen.de. Furthermore, while the build system creating the nightly build checks out all TRex sources from SVN trunk every night, the nightly build system itself is not automatically checked out every night. Hence, after a change to the build system, you have to request from the maintainers a manual check out of the nightly build system itself.

How to add a new plug-in to TRex?

If you add new plug-ins or change the existing plug-in structure, it is not sufficient to reflect change this in the SVN repository. Please perform additionally the following steps:

1. Update the Plugin Structure page.
2. Update the Building TRex manually page.
3. Update the automated build system as well by adjusting the de.ugoe.cs.swe.trex.build plugin where all TRex plug-ins are referenced in the build.xml* and customTargets.xml* files; to propagate these changes to the nightly build system, you must also inform the maintainers to make sure that they update the nightly build system as well.
4. Make an announcement to the developers mailing list to make sure that every developer checks out your additional plug-in as a new project from the SVN repository.
5. Add the following SVN properties to the top level directory:

svn:ignore	.settings
	bin
bugtraq:url	http://www.trex.informatik.uni-goettingen.de/jira/browse/TTC-%BUGID%
bugtraq:label	JIRA Id: TTC-
bugtraq:message	TTC-%BUGID%
bugtraq:logregex	TTC-(\d+)
	(\d+)

How to prepare TTCN-3 files used in JUnit tests?

Those JUnit tests involving the TTCN-3 formatter use the default formatter settings. Therefore, when preparing TTCN-3 files used for comparison with TRex output, use the default formatter settings as well. In particular, different line break styles (Unix vs. Windows) often make problems, e.g. the file offsets are wrong. When copying TTCN-3 reference files using copy and paste, the line break style (and thus file offsets) may change! Note that the JUnit compare dialog does not display such white space differences.

How to change an SVN commit log comment?

If you need to change a commit log (because you have entered a wrong JIRA bug ID), contact the maintainers. While the actual change may be performed via an SVN client (Subclipse: History view > Set Commit Properties), the Trac timeline needs also to be resynced (Trac caches SVN history in its database.). Since this takes some time, it is not invoked automatically by the pre-revprop-change hook, but trac-admin path-to-trex-trac-directory resync must be manually performed. (As soon as TRac allows intervals for resync, we may add it to the pre-revprop-change hook.)