There are a number of fairly simple steps involved in an upgrade from VisualWorks 2.5.x or 3.x to VisualWorks 7. The process runs something like this:
These tips are cribbed from this presentation from our German partner, Georg Heeg.
- Investigate the structure of the existing application. This means taking a look at the application and making sure that you can separate out base system changes from your own code. In an ENVY application, this is pretty simple - you just look and see which ENVY Applications that are part of the base have been modified. Those parts need investigation.
- Investigate System Changes During this step, look over the system changes identified above. This will include:
- Base code overrides (places where existing code was changed)
- Base code extensions (places where existing classes had code added
In either case, the developer must investigate whether the changes are necessary in 7 (perhaps it was a work around that is now addressed). The developer must also check to see whether changes made break in a 7 system.
Finally, if the application has custom (home brew or third party) widgets (GUI) that use polling, then the widgets must be migrated to the event system, as polling is no longer supported (it was deprecated as of VW 7.1):
- Port the widgets to the event system (look in the relevant 2.5.x documentation on the event system for details)
Also of note as of VW 7.1 was a change in the GUI system - there is no longer a single "distinguished" UI process. Instead, applications may have a process per window, or a process per group of windows. If the old application relies on the single process model, then developers will need to look at having all of their windows use the same process during the initial migration. To see how this can be done, look at class WindowManager.
- Reorganize the system At this point, code should be fully organized. So long as a port is being done, the opportunity should be taken to clean up the organizational structure of the system.
- Migrate from ENVY to Store Since ENVY is no longer supported, developers should migrate now. The Store bridge tools that ship with VisualWorks make this fairly straightforward, and there is supporting documentation. Roughly speaking, one exports configuration maps and imports parcels. The parcels become StORE artifacts, which may then be versioned. Developers should have either an Oracle, SQLServer, or PostgreSQL database available as a repository. Setting up the repository is well documented. Developers using VW 2.5.x cannot use the bridge, since parcel support is a pre-requisite. Never fear though - one can do the following
- File out all ENVY applications to be migrated
- Create a new Store Package for each Application filed out
- File the Application into the new Store Package
- When finished, the developer should create bundles analogous to the configuration maps in the ENVY system.
During migration to StORE, developers will find many ENVY applications that are no longer used. This is an excellent time to leave them behind.
Inevitably, some 'dead' applications will be migrated. Developers should identify those and remove them from the new bundles that have been made through the migration process.