More efficient handling of API and Impl in Rebuilds » History » Revision 2
Revision 1 (Henning Blohm, 17.02.2020 19:05) → Revision 2/12 (Henning Blohm, 17.02.2020 19:11)
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.
However: How to detect, that a rebuilt due to code changes is NOT necessary, when the sync indicated a new revision?
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>