Revisiting includes for 2.3

Related issues: #1492, #1481, #1491, #869

Discussion on how includes work today and how they should work to make sense for development with include based systems on a broader scope than what is used today.

How Includes work Today

There are to different cases: Include of a Java component and include of a files component.

Include of a files component

In that case, the files component is expected to have a src, bin/lib, bin/classes structure (like an API-only Java component). All resources are simply copied to the including Java component. There is no expection of compilability outside of the including component and there is no transitivity or anything else involved during resolution of the included resources.

This case is clear and simple and actually up to the original intention: Include of libraries with dangling imports like Spring's context support.

Include of a Java component

In that case, the included Java component is loaded (that is, in case it has sources, those will be compiled, and in case it has includes, those will be resolved). After it is loaded, it's API binaries (bin/lib, bin.api/lib, bin/classes, bin.api/classes) will be copied to the including component.

Hence it is transitive.

Developing with Includes

Use of adapter libraries via includes

The most prominent cases for this is Spring context support and Spring aspectJ support. These are the two prototypical cases of using a library that was build to either adapt one to many use cases (context support) or to adapt a class loading scope (spring aspectj).

In the first case, that is for Spring context support, a library that intrinsically has many unsatisfied imports will be used to provide utility types for some of many potential use cases. Instead of having 20 different adapter libraries, Spring chose to bundle all adapter types into one. Using the library via a reference would mean to either adapt its own references based on use cases (harming re-use consistency) or to add all adaptation targets to the re-use repo (equally bad).

In the second case, that is the Spring AspectJ case, the library associates a class loading scope with a Spring application context via its presence in the scope. That is, only inclusion implements its use-case in a modular environment.

Plugins based on Includes

As many drawbacks as this has in a modular environment, many plugin environments assume runtime inclusion of all extenders into one scope.

Assume the most basic case, that some codebase A can be extended by Plugins P1, ..., Pn and that assumes that P1, ..., Pn are found in the same class loading scope at runtime. At compile time, plugins require A.

We are looking for a setup that allows to conveniently develop plugins but at runtime executes A and all Pi in the same scope.


That is:

  • Have regular pure API modules for each plugin and the codebase A. All plugin module reference the shared codebase and hence they can be conveniently developed.
  • Add a runtime module that includes A and each plugin for execution within one runtime scope.

Updated by Henning Blohm over 10 years ago · 6 revisions