Classpath management is one of OSGi's features. Another is dynamic service registry and dependency management. So following that route, the Lift framework would define an interface that exposes much of what is currently found in Boot. Modules (OSGi bundles) would create implementations of that interface and register them during startup (fortunately the details are usually handled automatically). Lift would also define a manager class that listens to the registry and does whatever bookkeeping is required when modules come and go. Eclipse RCP is a great example of this in action. Note that defining a framework on top OSGi can also be a slippery slope. RCP is a good example of that as well; it's an extensive framework on top of OSGi. So, the question is whether it's worth turning what is currently a straightforward boot process into something that is more modular though more complicated. If so, a good first step would be to define that manager class and interface since these could be wired together by any means (Scala, OSGi, Spring, etc.) without necessarily branching too far. I can take a look if you all think it's worth it (and if Heiko hasn't already).
-Stephen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
