Community
Participate
Working Groups
The runtime workbench launch configuration, in its current state, is sufficient for testing RCP applications. However, there is definitely room for improvement. We will use this bug report to enumerate and address the list of features, both major and minor, that need to be addressed for RCP self- hosting to be as smooth as possible. Based on Nick's input and EclipseCon code clinic, we have the following items: 1. The About Dialog in the runtime workbench does not show feature info. 2. The addition of the new option "Use this plug-in and all its pre-reqs" has been helpful. We should allow the listing of more than one plug-in at at time. 3. if the user has a custom splash screen, he should be able to easily launch and see it upon startup.
cc the RCP guys to add comments and suggestions as we go along.
In Ed's tutorials, he includes a .launch file (or used to). This is nice, but AFAIK there's no way to avoid a hardwired path to the workspace, which may not be appropriate on others' machines. I believe Ed removed the .launch file for this reason.
Correct. The .launch files are generally not portable across platforms or machines because we have to save the workspace data location specified (and an arbitrary number of previous ones specified in the combo box). We have had a request from the Core team to be able to specify the location of the config area of the runtime workbench on the Configuration tab for advanced users. That would be another hardcoded path that we will have to maintain.
Yes, I removed it for the reason Nick gave. People immediately had trouble with it when they unpacked the project into their workspace because they didn't have a "d:\whatever" path like a did. Hardcoded paths have to be removed to make .launch files sharable between two developers. It would be nice to be able to check in a .launch file with the project (like I tried to) and have it just work. This isn't really an RCP issue though.
Wassim Melhem wrote: "1. The About Dialog in the runtime workbench does not show feature info." It's a bigger problem than that. The About dialog is IDE only, at least in M7. Even if it wasn't, launching a workbench with features is a terrible kludge right now that I've never personally gotten to work but some others have. What I think you want is to launch with all your branding active, which might not be quite the same thing as launching with features. "2. The addition of the new option "Use this plug-in and all its pre-reqs" has been helpful. We should allow the listing of more than one plug-in at at time." It's helpful, but dangerous. Without an export wizard that uses the same rules, people are having problems getting things to run outside of Eclipse that run just fine inside Eclipse with this launch option. What I'd suggest is to get rid of this option, and beef up the next one (Choose plug-ins and fragments to launch from the list). You need some extra buttons like Clear All, Select All, and Add Required. The Add Required needs to be smart enough not to add thing like org.eclipse.core.resources and org.eclipse.ui.workbench.compatability, and the exact same list/dialog should be used by an Export RCP Application wizard. "3. if the user has a custom splash screen, he should be able to easily launch and see it upon startup." This is the same thing as #1 in my mind (launch with branding). BTW if you launch with branding, some of the options in the launch config are supurfluous. Maybe they should be disabled, or maybe you should be able to export a launch config into a branding init file? I'm not sure what the best way is.
I was in the midst of planning for bug 73820, when I very quickly realized that the name Runtime Workbench is very misleading when it comes to RCP apps. Since I am planning to add a Run > Rich Client Application to the Run context menu of plugin projects, then this spills over to this defect, as it would mean that we need a new launch configuration type (Rich Client Application) in the launch configuration dialog for consistency. Thoughts? Good idea? Bad idea? Unnecessary idea? Another reason why I think we may need a new launch config type is the fact that the Plugins tab behavior when hand-picking plugins in the runtime workbench configuration is not suitable for RCP apps. I'll explain the subtle difference: When you hand-pick plugins from the workspace plugins group on the Plugins tab, we only save the id of the ones you "deselected". This is ideal for regular Eclipse developers because if you import plugins into your workspace after the selection/deselection process, these newly imported projects will get picked up by the configuration when you launch and you don't need to revisit it. This behavior is not suitable for RCP apps. If you hand-selected plugins, you would want to make sure that it is these plugins only that get picked up and nothing else.
cc Jeff as he might have input.
If we can have a common launch config for both the IDE and other RCP apps (the IDE is just an RCP app after all), then that would be simpler. I'm fine with an appropriate change in terminology if needed. For the plugin addition scenario, perhaps this could be handled with a "When a plug-in is added to the workspace, add it to this launch configuration" checkbox, rather than a whole new launch config type.
sounds good. Thanks Nick. We may need to be creative and come up with a better term.
How about "Eclipse Application" to replace "Runtime Workench"?
That thing about adding newly imported projects being added automatically bites me from time to time even with regular IDE plug-in development. Sometimes I want it to add, sometimes I don't, so I can't think of a good way to handle it with an option. "Eclipse Application" would be ok though I don't think the term Runtime Workbench is wildly inappropriate. If it said "Runtime IDE" that would be bad, but after all the Workbench is a core RCP facility. So I'm fine with either one.
If we change "Runtime Workbench" to "Eclipse Application", we might render Ed's book outdated :-)
I like Eclipse Application better, since you can now choose an arbitrary product or application, and it doesn't necessarily need to run on top of the workbench.
Name pf the launch configuration was changed to the zippier "Eclipse Application" Several buttons were added to the Plugins tab of the launcher to aid with plugin selection including the introduction of a "plug-in" working set. A validation button was added to the Plugins tab to validate the completeness of the selected set of plugins and pre-flag any errors.
