Bugzilla – Full Text Bug Listing
| Summary: | [releng] Add equinox concurrency bundle to e4 | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Scott Lewis <slewis> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | caniszczyk, contact, jeffmcaffer, john.arthorne, kim.moir, pascal, pwebster, thatnitind, tjwatson |
| Version: | 0.9 | ||
| Target Milestone: | 0.9 M2 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | 261953 | ||
| Bug Blocks: | 261952 | ||
|
Description
Scott Lewis
Is there a particular reason for adding it to the Eclipse SDK? It is now in the Equinox SDK so it is generally available in our builds and update sites for anyone who wants to install it... If jobs adds new provisional API to start using the futures API then it would likely need to be added to the SDK. If we do not plan to do that and there is no one else in the SDK that is planning to use futures then I don't think we must ship it with the Eclipse SDK. (In reply to comment #2) > If jobs adds new provisional API to start using the futures API then it would > likely need to be added to the SDK. Right...I've added bug #261952 to blocks list. If we do not plan to do that and there is > no one else in the SDK that is planning to use futures then I don't think we > must ship it with the Eclipse SDK. > We (ECF) have been expecting that the jobs support for futures will be in place in 3.5 SDK (as provisional), as we would very much like to use the JSFF in our own implementations that already use/depend upon jobs. John/Tom, should I be adding this bundle to the Eclipse SDK? If the API is provisional than I am +1 for this The work should be release to allow consumers to provide feedback so this functionality can be shaped in the future. -1 IMO, the argument that a bundle could be useful is not good enough to have that bundle included in the SDK. (In reply to comment #6) > -1 IMO, the argument that a bundle could be useful is not good enough to have > that bundle included in the SDK. > So what would be sufficient justification for adding any new provisional API to the SDK? Having it not be useful? Maybe a larger code size? :) This seems to me a poor and negatively-biased way of deciding whether anything new should be in the SDK. In my view there won't be very much actual innovation at this level if the bar is that many have been requesting something for multiple years, or that the characteristics of the requester(s) makes justification somehow 'easy'...or something similarly mysterious. In your view Pascal, what would constitute sufficient justification? It simply needs to be used by a component from the SDK and provide to this component significant value. Given how far along we are in the game, I'm kind of skeptical that any SDK component would start deeply using it now. I think that if it is of a high enough value, then it will get picked up and will end up being used. Also several you have mentioned to me and in different bugs that the ECF team is a small team and that you have limited time and resources, so I'm a bit worried that putting this in the SDK would put more strain on you guys. (In reply to comment #8) > It simply needs to be used by a component from the SDK and provide to this > component significant value. That seems a little circular...i.e. it has to be used by something in the SDK to get into the SDK. Wouldn't it make more sense to make the criteria be something like desired/used/consumed by multiple EF projects? >Given how far along we are in the game, I'm kind > of skeptical that any SDK component would start deeply using it now. Well, although ECF isn't technically an SDK component (although part of ECF is in the SDK), we're already using it deeply (to implement OSGi EE 4.2 RFC119 among other things). This work isn't yet part of the SDK, of course...but we think it will be a very important part of ECF's contribution to the runtime (and Equinox) project...as I *think* it represents the first time a non-Equinox project has taken on implementing part of OSGi spec under EPL, etc. In any event...I agree that it's unlikely that other sdk bundles would be able to use it for 3.5...but otoh if in the sdk other projects could then more easily consume and critique it particularly the E4 project, which was at least some of the impetus for the work (being more asynchronous). > I think that if it is of a high enough value, then it will get picked up and > will end up being used. Well, I think ultimately that this is right, but I think we also also know how difficult API adoption and usage is when it implies those extra user steps of knowing about the existence of the API outside of the SDK and having to then explicitly retrieve the API (e.g. via ECF). > Also several you have mentioned to me and in different bugs that the ECF team > is a small team and that you have limited time and resources, so I'm a bit > worried that putting this in the SDK would put more strain on you guys. Thanks for the thoughts...it is appreciated...but actually most of the strain for us has to do with build issues...e.g. satisfying Galileo req, p2/sdk integration, and others. In fact if we have to include the concurrent bundle in our own build and deploy it as part of ECF (which is what we will do if this request is rejected), this will increase our required effort on our own build/deploy. Sorry, but the bar has to be quite high to get something in the Eclipse SDK. That is a fact of life. We already have way too many APIs that are either not used or do very similar things. So the first way to get something in the SDK is to have the SDK use the new API. I think we are too late for that. The other way is to justify that multiple consumers of the Eclipse SDK are actually going to use the new bundle and we can weigh the cost of having another bundle vs its usage by the Eclipse SDK consumers. Right now I give a weak -1 because I do not think it is that hard for you to consume the bundle out of the Equinox SDK. If it is hard then we need to figure out why. The Eclipse PMC is discussing it today and will tell us whether or not to go ahead with this. There are very few Eclipse projects who would *not* want their bundles included in the Eclipse project SDK. There is even a large number of Equinox bundles that aren't in the platform, but would benefit from the wider exposure. If we accepted them all, the platform would be at least an order of magnitude larger than its current already bloated size. This is the reason for careful deliberation over what goes in and what remains as separately installable pieces. For this particular case, if it doesn't go into 3.5, I (and others) certainly want to use it in both 3.6 and e4, so rest assured it will eventually go in. (In reply to comment #10) > Sorry, but the bar has to be quite high to get something in the Eclipse SDK. > That is a fact of life. I don't mean to be impertinent here but my question is: why? I understand and fully appreciate that there are needs for stability for the platform. But what I don't think is being appreciated is that there are also needs for innovation for the platform. >We already have way too many APIs that are either not > used or do very similar things. I agree...but this also is not a reason to halt (or even slow down) innovation. It is certainly a reason do to triage and (perhaps breaking) deprecation. >So the first way to get something in the SDK > is to have the SDK use the new API. I think we are too late for that. The whole effort to take what ECF was doing WRT futures and make it available in Equinox so that there could be multiple consumers (ala E4s 'be more asynchronous') was started in fall of 2008. That doesn't seem last second to me (even though eventually requests such as this always seem to end up as 'last second' WRT SDK/PMC/releng). >The > other way is to justify that multiple consumers of the Eclipse SDK are actually > going to use the new bundle and we can weigh the cost of having another bundle > vs its usage by the Eclipse SDK consumers. I guess all I can currently say in response to this is bug #253777. But everyone realizes...I think...that we have a chicken and egg problem here...people can't widely use new API unless they know about it, have example usage, have it in their hands, etc. API can't be proven, moved from provisional to complete, etc without experience with multiple people using it. And multiple people have a (much) harder time using it if it's not in the SDK. IMHO, this makes for a *very slow* innovation cycle for the SDK (at Equinox/platform level). > Right now I give a weak -1 because I do not think it is that hard for you to > consume the bundle out of the Equinox SDK. If it is hard then we need to > figure out why. > Well, as I say in comment #10, it's not hard...it's just another straw on the back of our releng...but I doubt we are the only ones in that position. (In reply to comment #11) > The Eclipse PMC is discussing it today and will tell us whether or not to go > ahead with this. There are very few Eclipse projects who would *not* want their > bundles included in the Eclipse project SDK. This is not a case of ECF or any other project wanting their bundles in the SDK. This was intentionally moved/targeted toward Equinox specifically to make things available to other projects as per bug #253777. There is even a large number of > Equinox bundles that aren't in the platform, but would benefit from the wider > exposure. Of course...but they all are not Equinox-level API (nor should they be). what about adding it to the e4 feature for the next milestone? Should this bug be moved to e4? Jeff, was this discussed at the Eclipse PMC call? Failing adding it to the platform for 3.5 I think adding it to e4 certainly makes sense. Currently e4 has its own executor/progress runnable APIs, but should be using this common one instead. (In reply to comment #14) > Should this bug be moved to e4? > I don't care where this bug goes in the categorization, but doesn't the inclusion adding of a dependency in jobs (261952) imply adding it to sdk post 3.5? (and e4 I suppose) sorry, forgot to follow up here. we did discuss and decided NOT to add the concurrency bundle to the Eclipse SDK for Galileo. This was predicated on there being no users of the function in the SDK for that release. It should be part of the Equinox SDK. The e4 team is certainly free to add it there as well. Since this bundle is already part of the equinox sdk, I'm going to move this bug to e4. Paul, what is involved with adding a new bundle in the e4 build? We should use equinox.concurrent in place of the new e4 APIs such as IBackgroundRunner and org.eclipse.e4.core.services.IRunnableWithProgress. (In reply to comment #19) > Paul, what is involved with adding a new bundle in the e4 build? We should use > equinox.concurrent in place of the new e4 APIs such as IBackgroundRunner and > org.eclipse.e4.core.services.IRunnableWithProgress. > We just need to add it to the appropriate team releng map and a PSF file. If it's an enhancement to or at the Jobs level, does that mean it should be visible to the e4 resources work as well? PW > If it's an enhancement to or at the Jobs level, does that mean it should be
> visible to the e4 resources work as well?
It's not currently needed, but it may end up being useful there too. I guess the only difference is whether to include it in the e4 resources patch feature?
(In reply to comment #21) > It's not currently needed, but it may end up being useful there too. I guess > the only difference is whether to include it in the e4 resources patch feature? I guess I'm asking if it patches the org.eclipse.core.jobs bundle or not. If not, then I'll put it in its own feature with no dependencies so it can be installed for anyone to use. If it patches o.e.core.jobs, then we'll have to figure something out. PW It doesn't currently patch org.eclipse.core.jobs. There is another bug report about augmenting the jobs API to use equinox.concurrent, but that's a separate issue. Released for tonight's build. PW |