Project

General

Profile

Actions

More efficient handling of API and Impl in Rebuilds » History » Revision 11

« Previous | Revision 11/12 (diff) | Next »
Henning Blohm, 05.04.2020 23:16


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

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

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:

<module>/api
<module>/impl

For compatibility, we could consider

<module>/impl -(private)-> <module>/java/impl
<module>/java --(public)-> <module>/java/api

So overall we have

«Drawio diagrams are available only in issues and wiki pages»

Problems to Expect

This approach has a few downsides:

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.

Updated by Henning Blohm almost 4 years ago · 11 revisions