Revisiting includes for 2 3 - DONE » History » Revision 2
Revision 1 (Henning Blohm, 30.08.2013 10:35) → Revision 2/6 (Henning Blohm, 31.08.2013 12:35)
h1. 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. h2. How Includes work Today There are to different cases: Include of a Java component and include of a files component. h3. 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. h3. 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. h2. Developing with Includes h3. Use of adapter libraries via includes The most prominent cases for this But 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 it useful 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 developing plugin systems 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. h3. 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. *Approach:* includes