More efficient handling of API and Impl in Rebuilds » History » Revision 8
Revision 7 (Henning Blohm, 05.04.2020 19:16) → Revision 8/12 (Henning Blohm, 05.04.2020 19:31)
h1. More efficient handling of API and Impl in Rebuilds
Currently, in the dependency map used by the ComponentsBuilder, we analyze the necessity of a rebuild by comparing
build timestamps maintained in a dependency map in dependent components with a latest built timestamp kept in the
build lock file of the dependency component.
If there is a rebuild of an implementation part of a Java component, the build timestamp is updated and so a
rebuild of all dependency components forced - which is unnecessary, unless there was a change in the API as well.
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
h2. With the current model
At the level of the dependency component:
* Separate build timestamps for API and implementation as maintained in the build lock file.
At the level of the dependent component:
* When checking for rebuild in dependency components only check for matches with the API build timestamp.
* 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
h2. A new component split
The solution would be altogether completely natural, if api and impl as well as test would be different "Java" components.
We could have a simple layout:
<pre>
<module>/api
<module>/impl
</pre>
For compatibility, we could consider
<pre>
<module>/impl -(private)-> <module>/java/impl
<module>/java --(public)-> <module>/java/api
</pre>
So overall we have
{{drawio_attach(newjavadependencies_1.png)}}
h2. Acceptance Criterias
* There is a new component type *com.zfabrik.impl*
** The impl component is reduced Java Component that only supports a private loader.
** All sources are found in <Module>/impl/java, binaries in <Module>/impl/bin/{lib|classes}
** The impl component is always provided, even if not found in the module. In that case it is provided as a link to the java component.
... tbc
and *com.zfabrik.api*
h2. Problems to Expect
This approach has a few downsides:
h3. Missing Dependencies
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, if only the implemtation component is invalidated.
*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.