More efficient handling of API and Impl in Rebuilds » History » Revision 3
Revision 2 (Henning Blohm, 17.02.2020 19:11) → Revision 3/12 (Henning Blohm, 18.02.2020 09:30)
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 However: How to detect, that a cache of build results and copy from there, if no deemed necessary - because rebuilt due to code changes is NOT necessary, when the sources are not younger than the last build-timestamp 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>