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: Within the java component we have the following hierarchy: |/src.*, /bin.*|These are the immutable, repository retrieved resources| |/gen/<ts>/src.*, /gen/<generation>/bin.*|These /gen/<ts>/bin.*|These are the gen generations.| |/gen/depmap.properties|This is the latest dependency map for the latest gen generation and used to determine, if a new gen generation is 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>