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. Jeff On 2010-04-01, at 12:21 PM, Susan Franklin McCourt wrote: > We currently use ds in p2 to declare most of our services. > Yet we don't have any particular bundle that declares a dependency on ds. > > I can justify this in some respects - theoretically there could be clients > that consume the p2 bundles, declare their own services (using ds or > dynamically) and thus don't care about getting the default service > registrations. However this is not typical usage. Most people would expect to > get the ds-declared services, and right now they only get cryptic errors or > failed launches if they aren't using our features or product files and don't > know to include ds. > > For example, in a recent bug [1] , someone was getting a confusing error > because we forgot to include ds in the .product file for an example. We fixed > it by including ds in the product file. > > My question is - is this the right fix? > It feels a little strange that a consumer that doesn't declare any services > with ds still has to know that the bundles it is using declare their services > this way. > Is it intentionally left up to the configurer of the system to ensure ds is > included in the running target? Or should the bundles that declare services > with ds be requiring the ds bundle? > > susan > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=307558 > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
