Jean-Sebastien Delfino wrote: - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.)
There's several things here conflated together - I propose we tackle them separately. If you define runtime as a running SCA environment, I think we have a good start on a modular approach. There are bound to be tweaks but I think we are going in the right direction. We have a basic core with a well-defined SPI into which we can add extensions without needing any change to the core. We also have ways in which extensions can co-operate, providing new extension points themselves into which other things can plug. spi and core2 combined are about 12000 lines of code and the binary is just over 300K in size - this is not very big really. Having said that, I agree that we can restructure the SPI module to make things a little clearer. I think some of the confusion now comes because it contains both runtime and deployment interfaces. We agreed a long time ago that we wanted the runtime to be self-contained and independent of the deployment mechanism used. Bearing that in mind, we should be able to separate the runtime part of the SPI from the deployment part. Taking a quick swag at the top-level packages in the SPI I would propose we create two new ones, deployment and runtime, and move things around as follows: runtime: bootstrap, component, event, host, monitor, policy, services, wire deployment: annotation, builder, deployer, loader, model Assuming this works and all dependencies point from deployment to runtime we could then split the SPI module into two. I'd like to re-evaluate before doing that though as I think a typical usage would always have both runtime and deployment code and would typically always need both modules. Making people deal with two things just seems like unneeded complexity. Finally, I think we need to be clear about what is an SPI and what is an API. To me, an SPI is something used by an system to expand its functionality, it's a view from the inside looking out; an API is used by something else to manipulate a system, it's a view from the outside looking in. With that in mind I think some of the "SPIs" you mention above are really APIs. Things like deployment, install, admin (and I'd add management, monitoring) are interfaces the runtime would provide to allow outside entities to manipulate it. I'd propose that this may be a better way to slice up the current spi module. For example, we could consider splitting out the bootstrap and deployer packages into a new "api" module. The intention would be to provide interfaces used by external actors without exposing them to the mechanisms used to extend the runtime. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
