I added a paragraph to the Helios Migration Guide wiki about setting up DS if you want to take advantage of the the default Agent registration for the currently running system. I don't know if it belongs there (there is DS stuff buried in the Multiple Agent page), but it seemed the logical first place to look if your having trouble migrating to Helios. (My co-worker and I both encountered this problem when we tried to migrate to Helios.) And of course, someone who knows what they are talking about better than I do feel free to polish it up, just trying to be helpful.
-Jason On Fri, Apr 2, 2010 at 4:57 PM, Jeff McAffer <[email protected]> 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 <[email protected]> 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 <[email protected]> >> To: >> P2 developer discussions <[email protected]> >> Cc: >> Equinox development mailing list <[email protected]> >> 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* >> **[email protected]* <[email protected]> >> https://dev.eclipse.org/mailman/listinfo/p2-dev >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> >> >> _______________________________________________ >> p2-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/p2-dev >> >> > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > 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
