Hello David, On Oct 15, 2013, at 19:51 PM, David Jencks <david_jen...@yahoo.com> wrote:
> After seeing a lot of commit activity on DependencyManager I decided to try > to understand what it's for, and after looking at the documentation I'm still > not sure. It looks to me like the main feature is a fluent api that provides > something like DS, although less declaratively, and then there are some > special cases that might be slightly simpler than just declaring a service > that does the same thing (aspects, temporal) DependencyManager has its roots long time ago, when there was no Declarative Services specification yet. It started when I was working on my first big OSGi project (about 10 years ago) and we needed a library to help us declare and manage dependencies. The only library at that time was "servicebinder", which was somewhat similar to what became DS. We evaluated that library for our project, but it did not fulfill all our use cases. Most importantly, we had use cases that required us to declare dependencies at runtime, for example based on configuration data or some hardware aspects we discovered at runtime. Furthermore, I did not like the XML configuration, which did not automatically update when refactoring your code and did not have code completion or syntax checking. That last bit has been improved now that DS supports annotations to generate XML. > So as a DS partisan :-) I'm wondering what the big advantages of > DependencyManager are. DS still can't do dynamic dependencies, nor is it extensible to support new types of dependencies (DM comes with dependencies to track services, configuration, bundles and "resources". To give an example, DM can declare a component that requires service A and configuration B. As soon as it has both, the component can evaluate configuration B and depending on its contents add another service dependency C (or something like that). DM also has concepts like aspects and adapters, that allow you to declare factories that automatically generate components that attach to other services. In the case of aspects creating a whole "chain" of services, allowing you to easily intercept existing services and add behaviour such as adding a cache to a store. In the case of adapters allowing you to add for example management capabilities to services.. Just to name a few examples. This really deserves a longer description, but this gives you a general idea. A third feature that might be interesting is that DM also has support for "indices" that dramatically speed up the OSGi service registry when you're dealing with applications that consist of lots of services (1k-10k or even more). It uses a technique similar to what relational databases use to speed up lookups. Xander did a lot of work on this, they have a huge application that used to take about 30 minutes to start up and now does so in more like 30 seconds (so orders of magnitude speedup). > I also wonder if it would be useful to add to DS a fluent api for adding > components at runtime. I think this would be pretty easy, just construct > ComponentMetadata and add it to the appropriate BundleComponentActivator. Creating the fluent API would not be too hard, but DS is not dynamic, you need to package the XML with the bundle for it to work, so that part would be harder to fix (unless you resort to generating bundles on the fly or something like that). The other way round would be easier: creating an extender bundle that reads the XML descriptors that DS uses and using DM to create the appropriate components. For the record, DM currently also has an annotation based API, contributed a while ago by Pierre and Arjun. Greetings, Marcel
