Community
Participate
Working Groups
Activation of the org.eclipse.core.runtime.products ext. pt. allows easy customization of any RCP, such as the splash screen via the osgi.splashPath entry in the config.ini file. Additionally to the route via the deployed product the docs say, that the splash screen can alternatively be chosen via the osgi.splashPath VM argument. Using the Eclipse run configurator such a VM argument will not be used to show the corresponding splash picture, although the other product features like windowImages and appName **are** correctly shown. Please note that the corresponding osgi.splashLocation VM argument **does** work also in the run configurator.
the splash cannot be identified in the product because it needs to be shown way before the notion of "product" is available in the runtime. The current technique of specifying the splash path in the config.ini allows products to brand their configuration. Multiple products sharing a physical install can have different configurations and use the -configuration command line arg. We are certainly open to options for improving this situation but don't really see any right now. The addition of a -splash command line argument still does not solve the problem.
So why does the corresponding osgi.splashLocation work instead of the orgi.splashPath? I can't see the very difference.... Please note that I speak of the run configurator, not of normally deployed products.
Adding wassim just for fun and because the issue with running from a runtime workbench launch config is related to how PDE manages its config information. The challenge is in the searching for the plugin hosting the splash.bmp. If osgi.splashPath is set to contain some absolute paths then this should work. If the paths are not fully qualified then we search. The searching is relative to where the target's main is located and includes looking in "plugins" dirs etc. The runtime workbench or workspace setup/layout is somehow inconsistent with the search code and the splash is not found.
It is very possible that something needs to be tweaked in the launcher to find the splash screen in the right plugin. Jeff, if that is the only issue here, then please move the bug to PDE/UI.
I'll go ahead and move but I am not sure that is the only issue. There may be something we need to/can do in the runtime to help. Note that this is part of the bigger issue of exposing more of the configuration info in the launchers.
Jeff, from a PDE implementation point of view, this issue is trivial. I just need a clarification/feedback. 1. Do we need to expose a branding section in the launcher where people could enter the id of the branding plugin, OR 2. PDE should do it implicitly. For example, given the product that they choose in the "Program To Run" on the main tab, we use the contributing plugin for that plugin as the plugin housing the splash screen? In the case, where "an application is specified instead of a product on the main tab", we currently only show the splash screen if the application chosen is org.eclipse.ui.ide.workbench. If we were to remove the limitation, then we would definitely need to have a branding section in the launcher because we would not know for sure in this instance where the splash screen is. Thoughts?
I think the issue is somewhat more general. Developers do not have much control over the config.ini in the current setup. Ideally we would have a situation where a developer could write their config.ini in a project and then identify it to PDE as a "template". PDE would then use this template to produce the actual config.ini used in launching. This would be on a per launch config basis. Given this, PDE could then do transformations such as lookoing at the osgi.splashPath or osgi.framework.extensions values and substitute in the actual filepaths. This addresses a raft of issues: - how to manage additional system property settings defined by the runtime or other (user) plugins - putting the splash screen, framework extensions, ... in linked plugins (note that the runtime will have to do some work to enable this in normal launching scenarios)
With the exception of the splash location in which we are addressing in this bug report, what other config.ini values does the user not have control over (directly or indirectly)? Unless I'm unaware of something, I think the current launcher covers them all. osgi.bundles is computed by PDE given the list of plugins chosen and whether update.configurator is chosen or not. eclipse.application and eclipse.product are set given the user's choice on the first tab of the launch config. osgi.framework is set by PDE given the location of the osgi plugin. What other keys are there? Although using a "template" config.ini could be an "alternative" to what we have, I don't think it should be the standard way of doing things. People generally don't mind setting values in the launch configuration, but they do mind having to worry about and manage an extra file (config.ini). The "second" most popular comment I heard at EclipseCon that "there are just too many files to worry about", i.e. plugin.xml, build.properties, manifest.mf. And now config.ini? I am afraid that self-hosting is getting more and more complicated without us realizing it. If there is a deficiency in the launch config that leaves some config.ini keys out of the user's control (implicitly or explicitly), please let me know what they are so we could incorporate them in one way or another in the UI. By the way, the "most" popular comment I heard at EclipseCon was "Wassim, you don't look what I thought you were going to look like" :-)
Step back a sec. Why does launching need to fiddle with config.ini at all? It seems like that could be set up beforehand and simply used as is. If it's just to support the "Configuration" tab, I'd argue that tab should go somewhere else (like another page in the plug-in manifest editor). If it's so that all the plug-ins you listed in the "Plug-ins" tab can be listed out by name, I'd argue that's a pain in the petutty for RCP developers anyway who are left guessing about which plug-ins they need to copy to the deploy directory. Ok, it's another file, no big deal if there's a good reason for it. If you want to get rid of a file, get rid of the preferenceCustomization .ini file and put all that in the config.ini or maybe in plugin.xml directly.
For a complete and gory list of them, see the "Runtime options" help in the Plugin developer's guide "Other reference info" section. There are alot and those are just the runtime ones. You would never want to have a UI which did something special for all of these. You just want to get out of the middle and let people spec what they want and you copy/use. As for osgi.bundles, you can spec bundles and the start level but not whether not the bundle is started (see comments in canonical config.ini) When we add new keys we are basically hosed until PDE tools them. for exampel, we just added osgi.framework.extensions. Once we sort it out to ensure it is what we want we would tell you about it but in the mean time... I fully agree re: simplicity. If there is no template then PDE should continue to do the great job it does today and gen the whole thing. Note that hiding the config.ini is not really doing product developers any favours. They actually *need* to write their own config.ini. With the current PDE support they are unable to test it using a runtime workbench.
Re comment 9. yes. Under this approach we could actually just do a "config.ini editor" and allow people to point to a config.ini template. I would not put it whith Plugin editing. If anything it is more of a "product editor" function (if we had such a thing).
> Why does launching need to fiddle with config.ini at all? config.ini is read by the runtime upon startup, and PDE thus generates a config.ini and feeds it to the runtime with every runtime workbench launch. Therefore, it is not unnatural to give people the opportunity to manipulate the config.ini content at the launcher level. >If it's just to support the "Configuration" tab, It's actually the other way around. The Configuration tab was created to allow people to tell PDE what to put in the osgi.bundles key in the config.ini >get rid of the preferenceCustomization .ini file It is called plugin_customization.ini. I'm not too crazy about this file either :-) As for figuring out what plugins to choose etc., that is a separate issue which will be simplified when add such buttons as "Add RCP plugins" to the plugins tab of the launcher. Same for the future deployment solution coming soon. Note that with the current launcher, you NEVER have to list all your plugins on the config tab or even be aware of that tab. PDE does what is best for you. If update.config is among the plugins chosen on the plugins tab, then PDE puts core.runtime and update.configurator on the osgi.bundles key. If not, then PDE automatically puts all the plugins on the osgi.bundles key. I took a look at the Runtime options list in the Help content, and the list is pretty healthy, and evergrowing. We certainly cannot contain them all in the launcher, and therefore the launcher must support launching with a "template" config.ini. This request was filed by (my good friend) Pascal in bug 72274. Incidentally, the same reason why PDE should not try to contain all the config.ini args in the launcher can be used to argue that PDE should not invest in an editor for the config.ini file. The list of keys is long and evergrowing. Having looked at the keys, there is no rhyme or reason or logical grouping of keys that we can use to come up with a sensible editor that provides add-on value. The editor would just end up being labels and text fields, which is not much better than a text editor. So before we start boiling the ocean, here are the three themes that are most important from a PDE point of view and how we will address them: 1. Launching for people who are not developing an RCP app should remain as simple as ever. They must not have to worry about a config.ini, branding, etc. 2. RCP app developers should not unnecessarily be exposed to a config.ini file or a configuration tab. They would only to do two extra things over group 1. The first thing would be choosing the list of plugins on the Plugins tab. This step will be simplified by the buttons referenced above. They might also need to specify the location of the splash screen if PDE cannot correctly guess it. That is what my questions in comment #6 were about. Users don't need to list all the plugins on the config tab as PDE will correctly fill out the osgi.bundles key with every launch. 3. People who want to use a custom config.ini file should be allowed to do so and PDE should not stand in their way. This would be addressed in bug 72274. I think this would make most people happy, would not impede anyone's productivity and would not complicate self-hosting more than necessary. One question remains: Given that in cases 1 and 2, PDE correctly guesses the osgi.bundles key for the launch, should the table of plugins on the config tab be removed? The table might become unnecessary since the people who want a fine control over what plugins to start and at what level might be the same group as case 3, where they would supply a template config.ini
> config.ini is read by the runtime upon startup, and PDE thus > generates a config.ini and feeds it to the runtime... Well technically so is my main class file but PDE doesn't generate that. :) I've never had a need for that table in the Configuration tab myself but maybe others have. I still find the option to clear the configuration area to be confusing (I'm sure you understand it but... :). Should all that be replaced by an option that says either 'generate a config file automatically' or 'use the following config file'. If you had a config.ini editor it would only need to support the most common options in the GUI and anything uncommon could be handled by the source pane. For example, specifying the product name and a way to manage the plug-in list (either automatically or manually) might be good candidates for the GUI.
>Should all that be replaced by an option that says either 'generate a config >file automatically' or 'use the following config file'. Ideally, that is what I would like to see. The table, or more accurately the entire config tab, was originally added to allow the runtime team and other equally courageous people to mess around with the startup bundles. Since they are now asking for a template config.ini, then the table becomes unnecessary. The best way to figure out if any other people were using the table is to remove it without warning and see if anybody opens a blocker against us <g>. >I still find the option to clear the configuration area to be confusing The configuration area can now contain preferences and other metadata stored by plugins, so for testing, developers might need to clear that data every once in a while. Plus the config area for a launch is in a deeply hidden location that cannot be easily located by mortals, so having the checkbox is pretty handy.
The configuration tab can likely be gutted BUT.. the clear configuration area should remain. As Wassim points out, there is lots of stuff in the configuration area. The generated config.ini is just one element. > Since they are now asking for a template config.ini, then the table becomes unnecessary. I feel compelled to point out that from the start we wanted a template config.ini but we got a configuration tab. Now we are reasserting our desire. > One question remains: Yes. This would likely be fine. > Incidentally, the same reason why PDE should not try to contain all the > config.ini args in the launcher can be used to argue that PDE should not > invest in an editor for the config.ini file. There is an element of truth to this but I'm with Ed here. There is significant enough known and potentially complicated function in config.ini that a specialized editor may make sense. Note that the same characteristic cna be seen in the manifest.mf file. The runtime and dependencies tabs expose higher level views of the contents of this file (thankfully) but the file itself is completely open ended.
you might be interested in bug 73541
The problem with the splash screen in the launcher has been fixed. The config.ini issue will be addressed in bug 72274.
