> >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.
+1 to all of that.
