Community
Participate
Working Groups
Build Identifier: Helios final The title says it all basically. With a product based on the Eclipse RCP and Eclipse Help features, the help system will not start. Inspection of the logs reveals that this is due to the org.eclipse.ui.forms plugin missing. Reproducible: Always
Created attachment 175664 [details] Testcase Testcase instructions: 1) Please import the given projects 2) Launch the product (/my.rcp.product/my.rcp.product) 3) Notice the error message in the console and that hitting the Help buttons in the menu bar doesn't work 4) Now edit the feature (/my.rcp.feature/feature.xml) and add the plugin org.eclipse.ui.forms 5) Throw away the old launch configuration and run the product again. Now it works
I agree that org.eclipse.ui.forms should be moved to the org.eclipse.help feature. Kim, can you see any reason not to do this?
Created attachment 183052 [details] patch
Created attachment 183053 [details] mylyn/context/zip
John, please approve this feature change.
Bundles in the help system have several prerequisites that are not included in the help or RCP features - org.eclipse.ui.forms, org.eclipse.core.variables, and perhaps others. These were included in the help feature in the past, but were moved out in 3.5 (see bug 256345). See also bug 294541. I guess this comes down to a packaging vs. provisioning problem. If you provision (install) the help feature using p2, then all prerequisites at the bundle level, such as forms and core.variables, will be installed for you. However for packaging purposes some of the tooling assumes that features are transitively complete (satisfy all their own bundle-level dependencies). Jeff I know you are keen on this topic as it comes up often in RT and target platform contexts. What are your thoughts here? Some possible approaches: 1) Just put bundles back down at the lowest level they are needed to satisfy dependencies. I..e, put ui.forms, core.variables, and anything else needed by help, into the help feature. 2) Create a new "help system" feature that can be used to craft products and targets, which includes org.eclipse.help, and all its bundle-level dependencies. This feature wouldn't be in the Eclipse SDK, but would be in our repository for those crafting targets and products. 3) Find the places in our tooling where we assume features satisfy all their own bundle-level dependencies, and change them to use p2 provisioning so that these dependencies are satisfied.
Jeff, I forgot to CC you. See comment #6.
(In reply to comment #6) > I guess this comes down to a packaging vs. provisioning problem. If you > provision (install) the help feature using p2, then all prerequisites at the > bundle level, such as forms and core.variables, will be installed for you. > However for packaging purposes some of the tooling assumes that features are > transitively complete (satisfy all their own bundle-level dependencies). > > Jeff I know you are keen on this topic as it comes up often in RT and target > platform contexts. What are your thoughts here? Some possible approaches: We have some experience differentiating between "standalone" and "addon" features. As the names imply, an addon feature *includes* just the function you want to add on to an existing configuration. The prereqs are required presumably by the included bundles or may be feature level requirements as needed. This sounds like what we have now. The standalone features *include* more stuff. How much more is hard to say. Usually this is based on some expected usage pattern where certain things will be available and others will not. Sounds like what we had before. Keep in mind that the features we deliver are not the only features in the world. They are there both to capture missing dependencies (services, providers, etc) and create easy to consume groups. Other people will have different views on what is needed. Somewhat separately, features should include things to which they are tightly bound and where it is unlikely that random versions will work together. As always, there the reproducibility problem. If, for example, no feature includes ECF then using p2 we would still get ECF installed (providers aside) but there would be less control on the precise version. Back to the need for lineups. > 1) Just put bundles back down at the lowest level they are needed to satisfy > dependencies. I..e, put ui.forms, core.variables, and anything else needed by > help, into the help feature. would rather not do this > 2) Create a new "help system" feature that can be used to craft products and > targets, which includes org.eclipse.help, and all its bundle-level > dependencies. This feature wouldn't be in the Eclipse SDK, but would be in our > repository for those crafting targets and products. This would be a "standalone" feature. The question would be what is assumed to be there already. > 3) Find the places in our tooling where we assume features satisfy all their > own bundle-level dependencies, and change them to use p2 provisioning so that > these dependencies are satisfied. Would be good to do this regardless. For example, see Bug 328424. If we had some sort of lineup story then the use of requirements would be much more feasible. We may still need a line up story of some sort.
John and Jeff, I will defer to your judgment on what to do with the help feature. The only consideration that is important to me is that it be easy for an RCP developer to pull in all the bundles required to support help. Maybe the help feature was the wrong approach to this, if so we may want to get rid of the help feature and move the bundles back to other features.
*** Bug 294541 has been marked as a duplicate of this bug. ***
From the comments, I didn't understand the path to go forward, if this change should be implemented or not.
I agree with jeff's comment #8 that we shouldn't just push bundles down to the lowest feature that needs it. The only potential action for us here is to create a "standalone" help feature that we include in our repository but is not used directly by the platform and SDK. It would be a feature that includes org.eclipse.help, and all the necessary prerequisites to get help running on top of RCP. In short I view this bug as an enhancement request to introduce a standalone help feature.
okay thanks, will change the title
I'm not sure that I can agree with this conclusion. As far as I'm concerned, I'm using the org.eclipse.help feature as an addon to give an RCP app based on the org.eclipse.rcp feature help functionality. So I do consider the existing help feature an addon already (and I see no need for a standalone feature, I might add). The question arises, what is the baseline? I would suggest org.eclipse.rcp as baseline and this is why I would suggest to simply add all plugins here that are needed to get help running in an RCP app - for the most part this is working already after all, just the forms plugin is missing!
(In reply to comment #14) > As far as I'm concerned, I'm using the org.eclipse.help feature as an addon to > give an RCP app based on the org.eclipse.rcp feature help functionality. yes, the terms are not the best because you are almost always adding on to something and almost nothing "stands alone". Suggestions for better terms are more than welcomed. > So I do consider the existing help feature an addon already (and I see no need > for a standalone feature, I might add). The question arises, what is the > baseline? I would suggest org.eclipse.rcp as baseline and this is why I would > suggest to simply add all plugins here that are needed to get help running in > an RCP app - for the most part this is working already after all, just the > forms plugin is missing! From comment 8 > The standalone features *include* > more stuff. How much more is hard to say. Usually this is based on some > expected usage pattern where certain things will be available and others will > not. So the remaining topic (other than naming) is exactly determining what the baseline is. org.eclipse.rcp seems like a fine starting point.
pretty sure this was basically fixed long ago, with the introduction of the org.eclipse.help.infocenter_feature Please re-open if I've misunderstood what's being requested and how "Info Center" doesn't cover it. I'm going to mark fixed in 3.7, but might have been 3.6?
