|Re: [p2-dev] who should declare dependencies on ds?|
It should be up to the system integrator. Actually, there should be metadata (in p2) that expresses the need for various services to be present to make the integrator's job easier but ultimately inclusion/activation/... are in the eye of the beholder. So we should not cod classpath (bundle or package) dependencies, rather we need more markup in p2 metadata to capture these non-classpath-related dependencies.
More detail: In this case you could declare a package dependency on the ds package but that will only get you the interfaces and not the implementation. The producer could similarly declare a bundle dependency on the Equinox ds bundle. This is short sighted as there are other DS implementations. Various p2 features could include the Equinox DS bundle. This is better but suffers from the same problem--that feature would not be usable with other DS implementations.
Note that the problem is a friend of the HTTP service, Help system and myriad of other situations where people need a service to be there but there is no clear declaration of that dependency.
Note also that simply having DS there is not enough. It needs to be started. This is a product/launch level concern (i.e., the DS bundle can/should not say that it should always be started).
So, unless the p2/ds problem is burning, it would be better to address the underlying issue than ad hoc addressing of the symptoms.
On 2010-04-01, at 12:21 PM, Susan Franklin McCourt wrote: