z2-Environment

Problem¶

Currently there are two ways recompiles are triggered without updating the component revision:

• due to updated includes
• due to updated dependency components.

The side effect of these are problematic:

• compiled resources may be used by several z2 processes (incl. embedded in hadoop for example).
• jar caches (intentional / unintentional) stop functioning, once the files get overwritten without eviction from the cache
• on windows, overwrite due to the previous bullet point may even be prohibited.

Suggestion¶

This is not actually about the revision (which is compiled from the repository and can be introspected regardless of the component type), but rather about making sure we have cleanly separated gen generations. So here is the proposal:

1. We introduce an instance concept: At startup a z2 home or an embedded z2 determines an instance number of 00 to 99 and locks it for as long as the process is up.
2. This is the instance number of the z2 runtime and can be used as an additional runtime separating dimension
3. For Java component resources this is used as follows:
   1. We leave the original resource folder for the revision untouched. The build process
      prepares an instance specific resource folder as sibling to the original resource
      folder. I.e. rev A has an instance folder A_00 and so on.
   2. The "runtime resources" folder holds a copy of all original resources and may subsequently be modified by the compilation process.
   3. The "runtime resources" folder is available from the IJavaComponent API.

Doing these changes has some non-trivial impact on all tools that access java component generation resources. To this end, enhance the IJavaComponent to provide the latest gen generation folder.

Updates required in:

• JarRetriever
• Distribution Exporter
• Eclipsoid