Bugzilla – Full Text Bug Listing
| Summary: | Add support to run a runtime-workbench from a configuration located in the workspace | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Pascal Rapicault <pascal> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | ed.burnette, jeffmcaffer | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.1 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Pascal Rapicault
If you supply a config.ini as a template, then PDE would use it as-is and of course replace the plugin IDs in osgi.bundles, osgi.splashlocation with real accurate plugin URLs. What if your template was lacking keys such as splashLocation, or any of the basic keys that PDE automatically generates? did you want us to augment the template with such keys upon launching or no? I don't know about Pascal but I'd rather that if I specified a config.ini it not be touched, augmented, folded, stapled, or mutilated in any way. If it's going to fail, let it fail here in the controlled self-hosting environment rather than after deployment. Or put another way, I believe it should be a design goal that if anything is going to fail when deployed it should also fail under a self-hosting scenario. Why? Because I'm tired of trying to help people (including myself :) find out why their program works fine under Eclipse but when they exported/deployed it, it stops working. That's >50% of the RCP questions I get. well said :-) The only mutilation we will do is the plugin URL substitution, which should not affect the behavior at deployment when all your plugins coreside in the same directory. I was also thinking of something untouched, however I believe that it could be good for Runtime if PDE was doing some massaging of some wellknown values so the runtime does not have to be cluttered with self-hosting specific code. For example I would like to avoid having to add some code in startup.jar to look for plugins in the workspace to show the splash screen. In this case it could be good if PDE could massage the value. I understand the danger but the user could be warned when actually PDE does more than the real runtime. As Jeff was remembering me, PDE is the tooling for Runtime which defines the P of PDE :-), so it is good if it can save to do too many wacking things. Otherwise two other notes: - The configuration location is determined by the config.ini file, which means that the folders will all be generated in the workspace - In the config editor, I think that the user should be prevented to enter some values (for example filter from the plugins the one that can provide a splash screen). >PDE is the tooling for Runtime which defines the P of PDE :-) More accurately, Pascal puts the P in PDE :-) >The configuration location is determined by the config.ini file, which means >that the folders will all be generated in the workspace Not sure this will work. The idea here is to use the user's config.ini as a template only. So when we feed the config.ini to the runtime upon launching, the config.ini would have undergone some transformation with respect to splash location and URLs in the osgi.bundles key. So unless you want your config.ini to be overwritten, which I am certain you don't want that, the configuration area cannot be the same as the location of your template. Incidentally, while I am reworking the Config tab, I will also address bug 64495, to enable the user to specify the config area location if they want or keep the location managed by PDE. Done. Wassim, if you would, could you post a short note about how this works and how it should be used (or point to somewhere else where you've already described it)? For example where do you tell it where the config.ini file is; does it have any variable substitutions in it; is it modified; do any wizards generate and activate the config.ini for you; etc. Thanks. Created attachment 14952 [details]
Configuratin tab as it will appear in 3.1M3
The story will actually be very simple, yet it will empower you to do all the
things you were not able to do with the old configuration tab.
First thing you will notice is that you can now specify the location of the
configuration area, should you choose to. The default for this option would
remain as-is, ie. PDE will automatically generate a unique location for the
config area in its metadata.
As for the config.ini template selection, you either ask PDE to generate one for you (this is the default) or you could browse the workspace for an existing config.ini file. With the default, PDE will do what it has done up until now: PDE will generate a config.ini that is identical to it has done up until 3.1M2. If update.configurator is in the list of plugins, then the osgi.bundles key would contain only core.runtime and update.configurator at auto start levels of 2 and 3 respectively. If update.configurator is not in the list, the osgi.bundles key will contain core.runtime at autostart level 2, and we will enumerate all other plugins chosen, none of which will be autostart. Now, if you choose to supply your own config.ini, then we went here with simplicity. We want you to use the config.ini that you would like to ship with your product as-is, without requiring you to put substitution variables, etc. So you would compose your config.ini as per the instructions given in the template config.ini that comes with Eclipse, ie. the one in <eclipse_install>/configuration/config.ini. Upon launching, if you chose to supply your own config.ini, PDE will read that file into a Properties object, and modify the osgi.splashPath, osgi.framework, and osgi.bundles key to put specific URLs on locations of bundles, since at development your plugins do not coreside and can be coming from all over the place. For example: if your template config.ini contains: osgi.splashPath = platform:/base/plugins/com.example.xyz PDE will replace that with osgi.splashPath = file:D:/some_location/com.example.xyz For the osgi.framework, we do the same, if osgi.framework = platform:/base/plugins/someplugin or osgi.framework = someplugin PDE will strip the platform:/base/plugins/ from the string, if found, and will search for a plugin by the id 'someplugin' in the list of plugins to launch. If found, it will replace the value of osgi.framework with the url to the plugin. If not found, we leave everything as-is, untouched and let you crash on startup. The last key that we touch is the osgi.bundles key. Similarly here, the syntax your file should use is exactly what the runtime expects in startup scenarios: osgi.bundles = org.eclipse.core.runtime@2:start, com.example.xyz, com.example.abc@3:start, etc. We first split this key into tokens with the "," as a delimiter. For each token, we try to locate the id. The id is either the entire token, or the token up until @ or the token up until : If any of these attempts match a plugin id from the list of plugins to launch, we substitute the id with the full url and we keep the rest of the token intact. For example, org.eclipse.core.runtime@2:start will become reference:file:D:/somelocation/org.eclipse.core.runtime_3.1.0/@2:start Note that the config.ini that we launch with is NOT the same as the one you specified as a template. So when I say 'modify' this or that, the original template is untouched and all the modifications go into the config.ini PDE generates on the fly and puts in the config area of the launch. Thanks for the info. What was your thinking for making the template an absolute path instead of a resource in the workspace? Also how do you see this relate to exporting? I think the idea would be that PDE would simply copy the template during exporting and not munge it at all, right? Finally, instead of rewriting the platform: URLs in a temporary config file, wouldn't it be easier to have -dev mode interpret those URLs in a different way than normal, consulting some PDE specified setting that would map them into the scattered file: paths at run time? Hmm... I could see uses for this kind of mapping in non-runtime-workbench environments too, like an RCP app that needed to have a nonstandard directory structure for some reason. >What was your thinking for making the template an absolute path instead of a >resource in the workspace? Although the path shows up as absolute, the browse button actually browses the workspace. All other locations in the launcher are absolute, so this one is also made that way for consistency. >I think the idea would be that PDE would simply copy the template during >exporting and not munge it at all, right? right. >wouldn't it be easier to have -dev mode interpret those URLs in a different >way than normal, consulting some PDE specified setting that would map them >into the scattered file: paths at run time? PDE is the runtime's (good-looking) brother, and I think it's best if PDE did all the work and just fed it to the runtime. >>I think the idea would be that PDE would simply copy the template during >>exporting and not munge it at all, right? >right. I find comment 9, 10 and 11 to be contradictory so please clarify. In comment 9 Wassim is saying that PDE will munge the config.ini by doing various replacements. In comment 10 Ed suggests the PDE NOT do this munging. In comment 11 Wassim agrees. However, the behaviour outlined in comment 9 seems key to this facility being useful. +1 for comment 9. >>wouldn't it be easier to have -dev mode interpret those URLs in a different >>way than normal, consulting some PDE specified setting that would map them >>into the scattered file: paths at run time? >PDE is the runtime's (good-looking) brother, and I think it's best if PDE did >all the work and just fed it to the runtime. +1 for Wassim here. The runtime is not in a position to understand all these development time setups. PDE is the dev tooling for the runtime so it makes sense for it to tell the runtime what to do. The particular question that I agreed to in comment 10 was related to exporting, not launching. When it's time to export an Eclipse product, then if the config.ini is already hand-crafted by the user, PDE would not touch it when packaging the product. What I mean was that maybe PDE should tell the runtime what to do by specifying some path mapping options instead of by modifying config.ini. I agree Runtime shouldn't have any built-in knowledge of the dev environment. re comment 14. Right but I would say that if PDE figured out the mappings, why not just apply them rather than putting this development tooling code in the runtime. Ideally we would like to get rid of all the -dev handling code in the runtime. It is complicated and confusing in some cases duplicated. Further it is totally unneeded in production. However, it works now and there are bigger fish to fry. |