Bugzilla – Full Text Bug Listing
| Summary: | [repo] Server-side support required to advertise service for ECF discovery | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Susan McCourt <susan> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | bernhard.merkle, bugs.eclipse.org, Ed.Merks, irbull, jeffmcaffer, mik.kersten, mlists, neale, pascal, remy.suen, simon_kaegi, susan |
| Version: | 3.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 218534 | ||
|
Description
Susan McCourt
Here is the relevant discussion from bug #218534. ---------<Susan>--------- > Scott, I'm starting to think about all this for M5. As I understand it, from > reading http://wiki.eclipse.org/Update_Site_Discovery, the update site > discovery example you did last Eclipse-Con required server-side code to > (a) expose a local update site > (b) register the update site service with ECF. > > To discover p2 sites we would need some p2 variant of (b), correct? Or is it > just the same code? If I have an existing remote p2 repo, what do I have to do > it to enable discovery? Have you already done this exercise? > > From there, things are extremely simple on the client side. We shouldn't need > to worry about the ECF views or serviceAccessHandler or any of that stuff. We > would just need a small bundle that uses the ECF async listeners to listen for > p2 repositories, and send p2 DISCOVERY events whenever a new repo is > discovered. > Poof! discovered repos would show up automatically in the manage sites dialog. > ---------<Scott>--------- > > Scott, I'm starting to think about all this for M5. As I understand it, from > > reading http://wiki.eclipse.org/Update_Site_Discovery, the update site > > discovery example you did last Eclipse-Con required server-side code to > > (a) expose a local update site > > (b) register the update site service with ECF. > > > > To discover p2 sites we would need some p2 variant of (b), correct? > > Yes, I expect it would be some variant of it...because p2 has more than just a > single URL to discover (i.e. both metadata and artifact repos). > > Or is it > > just the same code? If I have an existing remote p2 repo, what do I have to do > > it to enable discovery? Have you already done this exercise? > > I've started it. By that I mean I started implementing a server that publish > properties including...(e.g.) p2 metadata repo location (uri), artifact repo > location (uri). > > > > > From there, things are extremely simple on the client side. We shouldn't need > > to worry about the ECF views or serviceAccessHandler or any of that stuff. We > > would just need a small bundle that uses the ECF async listeners to listen for > > p2 repositories, and send p2 DISCOVERY events whenever a new repo is > > discovered. > > Poof! discovered repos would show up automatically in the manage sites dialog. > > Yeah, I do think it will be nearly that simple for the client (good thing). > The question becomes though...what discovery protocols do we want to support? > The choices currently are > > a) Service Locator Protocol (SLP); > b) zeroconf/bonjour; > c) both. > > Markus Kuppe (our discovery API-focussed committer) is also on this bug (in > Europe tz) so that he can/should advise on some of these questions about > support in SLP, needed configuration/preferences, etc...as he's doing much of > the lead work on the discovery API and the providers for ECF 3.0 (Galileo). > ---------Markus--------- > Which discovery provider gets used (SLP/Zeroconf/Both) is IMO a deployment > issue and heavily depends on the architecture of the p2 update site server. > E.g. with which privileges does the server run? Is it just another Eclipse SDK > or will it be something that's supposed to be setup manually? > > Programmatically on the other hand, it doesn't matter which provider gets used > by p2 (client/server) anyway. ECF discovery is written to simply use whatever > is registered with the runtime. And here comes a question. Which ECF version is > targeted by p2 (2.1 or 3.0)? If you opt for 3.0, I'd suggest to use the "OSGi > way" and simply register an IServiceListener with the OSGi service registry on > the client (see bug #257861). On the server side however, lookup the > IDiscoveryAdvertiser via service registry and register the p2 IServiceInfos. > This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This issue died. |