Well, once the dust settles, I guess migrating old pier instances
people are using could raise all kind of strange issues. (not that I
am ungratefull for progress :)

That's a great point. One of the issues with Pier is how to upgrade to a new version - I found this particularly challenging on Gemstone as I ended up with multiple version of the same class (#classHistory size ~= 1) which caused strange bugs with class equality checks in the code-base.

One idea I came up with is to build an exporter which generates Pier kernel creation code based on the data currently in Pier - it's a lazy design as I only have to write an exporter not an importer. I've used it successfully on a few smaller projects but have yet to try it on more substantial projects.

The code is available in http://source.lukas-renggli.ch/pier2addons - package Pier-Exporter-Code.

To use it:

PRKernelCodeExporter exportKernel: (PRKernel instances detect: [: each | each name = 'pier']).

The exporter generates PierKernelCreator

and the kernel can be recreated with:

PierKernelCreator new createKernel

A Pier upgrade procedure could then be:

1) load PRKernelCodeExporter

2) export your kernel to code

3) try to regenerate your kernel

4) if 3 is successful then export the created code; PierKernelCreator

5) load PierKernelCreator and any of your custom Pier code into a Pier image with pragma support

6) Ensure that all add ons you use have been ported, including any of your own code using the porting guide outlined at the start of this thread.

I will add PRKernelCodeExporter class>>#exportMigratedKernel: which will generate #prototypeInstance initialisation for PRComponents, but first I'd like feedback if people think this approach is worth pursuing in theory and if so, in practice does the PRKernelCodeExporter work on your existing kernels?

Nick