Bug #1491
Updated by Henning Blohm almost 6 years ago
h2. 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. h2. 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: # 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 Within the process is up. # This is java component we have the instance number of following hierarchy: |/src.*, /bin.*|These are the z2 runtime and can be used as an additional runtime separating dimension immutable, repository retrieved resources| # For Java component resources this |/gen/<ts>/src.*, /gen/<generation>/bin.*|These are the gen generations.| |/gen/depmap.properties|This is used as follows: ## We leave the original resource folder latest dependency map for the revision untouched. The build process prepares an instance specific resource folder as sibling latest gen generation and used to the original resource folder. I.e. rev A has an instance folder A_00 and so on. ## The "runtime resources" folder holds determine, if a copy of all original resources and may subsequently be modified by the compilation process. ## The "runtime resources" folder new gen generation is available from the IJavaComponent API. required.| 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 From a component build perspective the following approach is implemented: # upon build check, we fetch the latest generation count *generation* from the locking revision file gen/tstamp # if no build is necessary, that *generation* is considered the current generation # if a build is necessary a new *generation* is chosen and eventually stored after build in gen/tstamp # runtime resource root is gen/<generation> Cleanup handling: TBC # after creation of a generation, there is a check