More efficient handling of API and Impl in Rebuilds » History » Version 4
Henning Blohm, 15.03.2020 10:54
1 | 1 | Henning Blohm | h1. More efficient handling of API and Impl in Rebuilds |
---|---|---|---|
2 | 2 | Henning Blohm | |
3 | Currently, in the dependency map used by the ComponentsBuilder, we analyze the necessity of a rebuild by comparing |
||
4 | build timestamps maintained in a dependency map in dependent components with a latest built timestamp kept in the |
||
5 | build lock file of the dependency component. |
||
6 | |||
7 | If there is a rebuild of an implementation part of a Java component, the build timestamp is updated and so a |
||
8 | rebuild of all dependency components forced - which is unnecessary, unless there was a change in the API as well. |
||
9 | |||
10 | We would like that a rebuild of dependency Java components is not forced, if there is no change of the API of a dependency component |
||
11 | |||
12 | h2. With the current model |
||
13 | |||
14 | At the level of the dependency component: |
||
15 | |||
16 | * Separate build timestamps for API and implementation as maintained in the build lock file. |
||
17 | |||
18 | At the level of the dependent component: |
||
19 | |||
20 | * When checking for rebuild in dependency components only check for matches with the API build timestamp. |
||
21 | 3 | Henning Blohm | * Keep a cache of build results and copy from there, if no deemed necessary - because the sources are not younger than the last build-timestamp |
22 | 1 | Henning Blohm | |
23 | 2 | Henning Blohm | h2. A new component split |
24 | |||
25 | The solution would be altogether completely natural, if api and impl as well as test would be different "Java" components. |
||
26 | |||
27 | We could have a simple layout: |
||
28 | |||
29 | <pre> |
||
30 | <module>/api |
||
31 | <module>/impl |
||
32 | </pre> |
||
33 | |||
34 | For compatibility, we could consider |
||
35 | |||
36 | <pre> |
||
37 | <module>/impl -(private)-> <module>/java/impl |
||
38 | 1 | Henning Blohm | <module>/java -(public)-> <module>/java/api |
39 | </pre> |
||
40 | 4 | Henning Blohm | |
41 | h2. Problems to Expect |
||
42 | |||
43 | This approach has a few downsides: |
||
44 | |||
45 | h3. Missing Dependencies |
||
46 | |||
47 | In many places provisioning of implementation instances via API provided lookups has been implemented. So, effectively an API dependent component holds on to an impl instance without being subject to a dependency that would invalidate the consuming component. |
||
48 | |||
49 | *Approach:* Upon lookup supply an object or a resource handle representing the dependant. Upon an object, its classloader will be inspected and the related Java component made a dependant to the providing implementation. Upon a resource handle, the identified resource will be made a dependant. |