Community
Participate
Working Groups
We should structure our configuration metadata in a way that can be reused by others. We want an IU that includes metadata for setting default start levels and default config.ini properties that people can include to get the same setup as the SDK. Currently, the SDK has no setup that is different that the platform. I suggest we use the current "toolingorg.eclipse.platform.ide.configuration" IU for reuse. This IU is currently automatically generated based on the platform .product file. I currently see 3 properties being set in here that aren't generally applicable to other products. These are: eclipse.application=org.eclipse.ui.ide.workbench eclipse.product=org.eclipse.platform.ide osgi.splashPath=org.eclipse.platform We should try and remove these properties from this IU. For the org.eclipse.platform.ide we can contribute these properties separately using the p2.inf. The other products, org.eclipse.platform.sdk and org.eclipse.sdk.ide should then reuse the toolingorg.eclipse.platform.ide.configuration instead of redefinining the configuration for themselves. The rcp products may already be in a reusable state, though I don't see any particular need to have the platform reuse the rcp. I will attach a patch that I think will do this.
Created attachment 135709 [details] patch Patch does the following: 1) platform.ide - platform.product file doesn't specify product or application or splash - p2.inf manually adds osgi.splashPath, eclipse.product, eclipse.application 2) platform.sdk. - platform.product - Don't specify any configuration info - p2.inf - add requirement on toolingorg.eclipse.platform.ide.configuration 3) sdk -> same as platform.sdk, don't provide configuration info require toolingorg.eclipse.platform.ide.configuration 4) buildAll - platform.ide must be generated first - platform.ide must be generated for all platforms, even if we don't install some of them, since the sdk will include the platform.ide metadata
Andrew, is this something that we should try to fix for 3.5?
Created attachment 135778 [details] Alternative smaller patch (In reply to comment #2) > Andrew, is this something that we should try to fix for 3.5? > I think we at least need to change org.eclipse.platform.ide so that we have something people can reuse. There is no real need to change the other products (except for them being somewhat exemplary). Here is a smaller patch that only changes the platform.ide product and leaves everything else as it was before.
Created attachment 135867 [details] updated alternative smaller patch updated patch to fix missing splash screen on mac
In the test build, all the platform zips have a log like this them ENTRY org.eclipse.osgi 4 0 2009-05-20 14:02:54.938 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: No application id has been found. at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:236) at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
We should look at this in 3.5.1
I'm going to officially close this as "won't fix" because we ourselves do not use re-usable configuration units any longer. In particular, the "configuration feature" was removed from all "products", though it is still created and put in our repository, in case some legacy users need it. But, obviously, since we don't use it, if there are issues with it, we depend on those legacy users to notify us if they need some change in it.
