This is the thing about decoupling bundles with services... Eggs do not depend on flour; they know nothing about flour. Flour knows nothing about eggs. We need some kind of knowledge that lives outside of the ingredients -- i.e., a recipe -- in order to make pancakes.
Rgds, Neil On Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer <j...@eclipsesource.com> wrote: > Good point Jason. I would generalize it even more and say that it is not > just DI but the decoupling that comes with services (or the extension > registry for that matter). We decouple bundles to they don't depend on > specific implementations but then do not have a mechanism for spec'ing that > they actually need an implementation. There is the component definition in > DS etc but p2 or someone else has to read/understand that. The unique thing > about DS is that it is even more removed. > > You could say , "hey, the bundle has DS markup so it must need DS" While > that is likely true in many cases, it is also possible that the same bundle > could be used with and without DS. It may contain other markup for other DI > mechanisms. These have to be dealt with at a higher level as you say. > > Jeff > > On 2010-04-02, at 4:40 PM, Jason Barkanic wrote: > > In general this is a problem with any kind of dependency injection, > although in this case nothing is actually being injected, but it is being > set up and managed by an outside component. > > Do you set up a dependency on the dependency injector? How do you best > notify clients that they need the dependency injection framework with your > config, or else they'll have to set things up themselves? It's not even > different implementations of DS, but you could substitute in Blueprint, or > Spring, without changing the API (that is if you don't define API to include > one particular set of bundles over another). > > This kind of thing is annoying though (I've been a victim). I'm interested > to see what solutions present themselves as more and more people move to DI > and Services paradigms. I think good error messages can help, since that > might have alleviated your 6 week search in the first place, but that is > easier said than done. The error message could make suggestions about why a > service lookup failed, but it's hard [impossible] to really know. > > -Jason > > > Phil Wrote: > ============================================================================================================= > > I can appreciate the desire to allow different DS implementations but the > bottom line is that DS is going to break any RCP application that uses P2 > (there may be other fall out as well). My RCP app uses P2 so I thought that > I should download 3.6M5 so that I had time to make comments about the API > before the API freeze. When I updated not only did my auto update > functionality break, but my build server broke also (PDE build with P2). It > took 6 weeks of googling before I figured out that there was this new DS > bundle that I not only had to include, but I also had to be responsible for > starting. > > All is well for me now, but I fear that this change is going to have a big > impact when 3.6 releases. At a minimum this needs to be documented probably > both in "What's New" in the "Plug-In Development Environment Guide" and also > in the 3.6 Plug-in Migration Guide. Getting the rcpupdate example updated > (bug 307558) was a good step in the right direction. > > Thanks, > Phil > > On Thu, Apr 1, 2010 at 1:50 PM, Thomas Watson <tjwat...@us.ibm.com> wrote: > >> Note that Equinox does have the ability to declare non-code dependencies >> in bundle manifests. See Eclipse-GenericCapability and >> Eclipse-GenericRequire headers at: >> >> >> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html >> >> This could be used by the DS implementation to declare a DS runtime >> capability and bundles defining DS components could declare a requirement on >> the DS runtime capability. But this mechanism only describes resolve time >> dependencies. It still would not solve Jeff's other concerns about the need >> to have DS active in order to truly work. Also note that p2 meta-data >> currently does not reflect the generic capabilities/requirements declared in >> a bundle manifest so even if we specified these today I don't think it would >> really help in ensuring a DS runtime is provisioned by p2. Perhaps we should >> consider adding that to p2? >> >> Also note that the OSGi alliance is currently looking at providing a >> standard way for declaring generic capabilities and requirements for a >> future core specification. We should keep an eye on this space and feed any >> additional requirements we may have to OSGi in this area. >> >> Tom >> >> >> >> [image: Inactive hide details for Jeff McAffer ---04/01/2010 11:46:32 >> AM---It should be up to the system integrator. Actually, there sh]Jeff >> McAffer ---04/01/2010 11:46:32 AM---It should be up to the system >> integrator. Actually, there should be metadata (in p2) that expresses the >> need for various servic >> >> >> From: >> Jeff McAffer <j...@eclipsesource.com> >> To: >> P2 developer discussions <p2-...@eclipse.org> >> Cc: >> Equinox development mailing list <equinox-dev@eclipse.org> >> Date: >> 04/01/2010 11:46 AM >> Subject: >> [equinox-dev] 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. >> >> 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*<https://bugs.eclipse.org/bugs/show_bug.cgi?id=307558> >> >> _______________________________________________ >> p2-dev mailing list* >> **p2-...@eclipse.org* <p2-...@eclipse.org> >> https://dev.eclipse.org/mailman/listinfo/p2-dev >> >> _______________________________________________ >> equinox-dev mailing list >> equinox-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> >> >> _______________________________________________ >> p2-dev mailing list >> p2-...@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/p2-dev >> >> > _______________________________________________ > p2-dev mailing list > p2-...@eclipse.org > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > >
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
