There are a number of fairtly simple steps involved in an upgrade from VisualWOrks 2.5.x or 3.x to VisualWorks 5i. 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 5i (perhaps it was a work around that is now addressed). The developer must also check to see whether changes made break in a 5i system.
Finally, if the application has custom (home brew or third party) widgets (GUI) that use polling, then one of two strategies must be followed:
- Ideally, port the widgets to the event system (look in the relevant 2.5.x documentation on the event system for details)
- Modify the 5i defaults so as to use polling instead of events.
In the latter situation, developers should revisit and port to events eventually, since polling will be fully deprecated in the 5i.4 release.
- 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 support is fading out, 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 al 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 migratiuon process.