Community
Participate
Working Groups
build I20040310 + latest from HEAD Platform.getProduct() returns null when self-hosting. In the implementation, Platform.getProduct() looks up the product id via System.getProperty(PROP_PRODUCT) but this property is only set if you specify - product on the command line. In order for us to migrate to using IProduct and IBundleGroup (bug 54547 and bug 54548), the Workbench should always be able to obtain an IProduct. For backwards compatibility, can the IProduct be inferred from the primary feature, as specified in the install.ini, if not specified explicitly?
This feels like an update or PDE issue. The runtime is not able to infer productness. It must be told. This can be done either via the -product command line option or the eclipse.product system property. The property can be set as a VM arg (-D on the command line) or in one of the properties files (e.g., config.ini). I believe previously PDE would build a platform.cfg that identified org.eclipse.platform as the default primary feature. If that is still true, then update should see that and generate a product for org.eclipse.platform. Assuming that is true, someone still has to tell the runtime which product is the current one (there may be many). On the UI side, getProduct() is spec'd to return null in the case where there is no product defined. There is no way for the runtime to enforce the presence of a product definition. Is it possible for the UI to use defaults when there is no product? Not sure where to move this so will add a few people to the CC list and see what they think.
In the platform.xml/platform.cfg that PDE generates for the runtime workbench, we do set the primary feature id if an install.ini file is found in the target platform and has such feature.primary.id key. PDE is not aware of -product xxx, but if the user (let's arbitrarily call him Nick, for a lack of a better name) enters it on the Prog Args field in the configuration, we just append it to the list of prog args that we load on the vmrunner. One thing I found suspicious in the PDE code, which may or may not have anything to do with this, is that if we find a primary feature id in the install.ini, we also automatically set the "-feature primaryfeatureid" prog arg. Right now, for some reason, we only set it only if the target platform is NOT an OSGi runtime. I don't recall why. Maybe it's a bug. Maybe there is a good reason for it. Maybe it does not matter.
Nick, it would be good if you could attach the platform.xml/platform.cfg that PDE generates for the runtime workbench. You could determine its location by: Go to the debug view > Right-click on the process corresponding to the runtime workbench in question > examine the value of the "-configuration" prog arg > Go to that directory on disk and attach the platform.xml/platform.cfg that you find. It would also be halpful if you paste the command line that PDE sets up for the runtime workbench, i.e. the entire content of the Properties dialog mentioned above.
To my knowledge, -feature is no longer used. The runtime certainly does not do anything with it. Update may do something with it. Perhaps this is the root of the conditional use of -feature in PDE?
This seems to be related to the bug #54283 comment #3.
Created attachment 8573 [details] Zip file containing platform.cfg and platform.xml I've attached the platform.cfg and platform.xml as requested.
Update does not use the -feature or any other flag. The update configurator defines a product provider, and the startup code is supposed to be selecting the desired "product". Update maps primary features to products. As Jeff suggests, I think PDE may need to set the -product (or create the appropriate entry in config.ini) instead of -feature.
PDE can only set it for the self-hosting case. Who sets it for the outer instance? It seems like only update.configurator could do this.
I think the config.ini has the product in it (or should have it). In the past we were relying on eclipse/install.ini for the default feature (aka default product), but Jeff and I were discussing having this info in config.ini that ships with eclipse.
yes, we "decided" that the install.ini info could be consolidated into the config.ini. I believe we should press forward on this.
more to the point, the interesting values in install.ini are now superceded by values in config.ini. - feature.default.id => eclipse.product - feature.default.application => eclipse.application I think the only use of install.ini is in update for the reconciler. If we setup the standard config.ini appropriately (i.e., to identify the product) and change the reconciler to read the product id and map it onto a feature, we should be happy.
Jeff, I am releasing code to set the eclipse.product variable if not already set. Its value will be the primary feature id, which is what is defined in install.ini, or org.eclipse.platform if undefined. After you make the changes to define eclipse.product inside config.ini, I will change the update code accordingly, and we can also scrap the install.ini file.
great. Lets do scrap install.ini after the I build tomorrow and test then put in M8 next week.
moving to Update. We resolved to remove install.ini and include eclipse.product and eclipse.application in the config.ini instead.
The update configurator is setting the product only when eclipse.product is not already set. So, if config.ini has the setting, update will not change it. Install.ini is still looked at to obtain the default feature it, but this code will be removed Monday (if install.ini is no longer part of the build) and get PrimaryFeatureId() will return the value of eclipse.product. Similarly for eclipse.application.
Can you remove install.ini from the build or do you want me to? Let me know either way
Jeff, it would be faster if you handle this. Thanks!
just to be extra clear on this, let me know when it is safe to remove the file.
Thanks Jeff. It is safe to remove it now. Update configurator works even when install.ini is not present.
Update configurator no longer reads the install.ini. The default feature is obtained from eclipse.product, and if not set it is the org.eclipse.platform. Similarly, the default application is obtained from eclipse.application, and if not set, it is obtained from the default feature (see above).
