Project

General

Profile

Bug #1491

Every Java-Re-compile must lead to new Java component revision

Added by Henning Blohm over 11 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
z2-core
Target version:
Start date:
29.08.2013
Due date:
% Done:

0%

Estimated time:
origin:

Description

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

Related issues

Related to z2-Environment - Bug #1481: java.privateIncludes: changed libraries are not invalidatedResolved13.08.2013Henning Blohm

Actions
Is duplicate of z2-Environment - Bug #869: Java component usage not safe in concurrent home usageClosedHenning Blohm

Actions
#1

Updated by Henning Blohm over 11 years ago

  • Subject changed from Java includes broken to Java include handling broken
#2

Updated by Henning Blohm over 11 years ago

  • Subject changed from Java include handling broken to Every Java-Re-compile must lead to new Java component revision
#3

Updated by Henning Blohm over 11 years ago

  • Description updated (diff)
#4

Updated by Henning Blohm over 11 years ago

  • Description updated (diff)
#5

Updated by Henning Blohm over 11 years ago

  • Status changed from New to In Progress
#6

Updated by Henning Blohm over 11 years ago

  • Target version changed from 14 to 2.3
#7

Updated by Henning Blohm over 11 years ago

  • Category set to z2-core
  • Assignee set to Henning Blohm
#8

Updated by Henning Blohm over 11 years ago

  • Description updated (diff)
#9

Updated by Henning Blohm over 10 years ago

  • Target version changed from 2.3 to 3.0 - Experimental/Retired
#10

Updated by Henning Blohm over 6 years ago

  • Status changed from In Progress to Closed

as dup

#11

Updated by Henning Blohm about 6 years ago

  • Status changed from Closed to In Progress
#12

Updated by Henning Blohm about 6 years ago

  • Target version changed from 3.0 - Experimental/Retired to 2.7
#13

Updated by Henning Blohm almost 6 years ago

  • Description updated (diff)
#14

Updated by Henning Blohm almost 6 years ago

  • Description updated (diff)
#15

Updated by Henning Blohm almost 6 years ago

  • Description updated (diff)
#16

Updated by Henning Blohm almost 6 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF