Hi, Am 23.02.2012 um 17:33 schrieb Jukka Zitting:
> Hi, > > On Thu, Feb 23, 2012 at 4:03 PM, Felix Meschberger <[email protected]> wrote: >> Hence I would go with OSGi from Day 0 and use the OSGi Service >> Registry as the mechanic for pluggability. > > The trouble with OSGi by default is that it brings in a massive and > pretty complex dependency with it. If you build your code with the > OSGi service registry in mind, it becomes difficult to run it in any > other environment, including in a simple JUnit test case. You're > basically making an assumption that all your deployment environments > will be OSGi frameworks, which dramatically reduces your potential > user-base. > > I don't want us to make that assumption. It should IMHO be possible to > embed the repository implementation to for example an Android app, to > a Maven plugin or a J2EE CMS without having to OSGify the entire > application. > > That doesn't mean we couldn't or shouldn't use OSGi for wiring things > up when the repository *is* deployed to an OSGi environment. Indeed > that's why I explicitly included those points in the roadmap. It's > just that we shouldn't make the core architecture depend on constructs > like ServiceTracker that don't work outside the scope of OSGi. Hmm, ok, let me rephrase it a bit (still I have OSGi in mind and my absolute requirement is that JR 3 must be deployable in an OSGi framework more easily than JR2). Here's my list of requirements : * Dependency Injection -- known to be a good thing for testing and supported not only by Spring but also by OSGi (Declarative Services and Blueprint and other non-standard ones). * Clear picture of configuration -- again injected à-la DI. * Proper separation of public API/packages and private implementation packages. * No static factories. These are a pain in standard Java but are dreadful in pluggable frameworks. * Create bundles from the start. These don't harm but allow us to testdrive in OSGi frameworks right away. Regards Felix
