What's different between OSGi Service tracker and Declarative Services

In OSGi, the ServiceTracker is a programmatic way to acquire a reference to a service. i.e. You write ServiceTracker code that "tracks" a reference to another service and let's you use it when it becomes available.

In contrast, Declarative Services (DS), allows you to declare dependencies that are injected into your component. DS is, as such, a form of dependency injection. The dependency graph between services, together with their start order will determine when your service starts. The cardinality property in a DS definition allows you to declare whether the relationship is mandatory (1..1), multiple with a least one (1..n), optional (0..1) or multiple optional (0..n). When you declare mandatory relationships, your service will not start until all dependencies are satisfied. When you declare an optional relationship your service will start regardless of the state of the dependency, but you need to take care in the code that the reference to your service might be null.

From a practical perspective, ServiceTracker is a lot of boilerplate code to write and maintain. Given the dynamic nature of OSGi services, there're many states allowed by the OSGi spec that need to be taken into consideration. DS will give you a clean way to declare and maintain your dependencies. Well-defined dependencies will help you maintaining consistency of your runtime environment.

Declarative Services (DS) are quite easy to use and you avoid some of the boilerplate code associated with the use of ServiceTracker. If you go plain OSGI, using the ServiceTracker only, you need to take care of some aspects of dynamic nature of OSGI services. Services can come and go and your component needs to deal with it. If you use DS, most of this work is already done. You just need to define references to other services and DS will inject those references when they become available. DS will activate your component when the component requirements are met.

If you use Apache Felix SCR annotations or the annotations provided by bndlib you can also avoid writing the xml required by Declarative Services. Recently the OSGI group also published their one annotations. I think the ones provided by bndlib and the ones from OSGI are very similar and I'm almost sure the bnd tool can process both.

I used Apache SCR annotations some time ago, but now I prefer to use bndlib because it includes annotations for Metatype and some classes that make the implementation of a Managed Service a lot easier. Metatype is a specification related to Managed Services. Basically, it provides metadata that can be used by Config Admin implementations to provide a more user friendly interface for configuration of a component.

I know of two other alternatives: iPojo and Blueprint.

iPojo is quite powerful and feature rich. It abstracts most of the OSGI stuff and includes some nice features like EventAdmin support and ConfigAdmin support.

I used Blueprint a bit, but because of the excessive use of xml I don't like it that much. I think you might say that Blueprint is like Spring for OSGI.

An OSGi Service Tracker let's you register listeners for certain services, so you can react when that service becomes available.

Declarative Services, on the other hand, implicitly uses the service tracker to delay the execution of your bundle activation code until the service dependencies have been solved.