Community
Participate
Working Groups
3.6 RC1 I built a target platform by using the PDE UI "Export Product" feature exporting a product. The product itself runs fine. Note, the export also created a "repository" next to the product install. It's also important to note that the product does not contain org.eclipse.core.runtime but org.eclipse.equinox.app and the config.ini is setup to launch an application. It also contains simpleconfigurator and a bundle.info with the necessary start level for org.eclipse.equinox.app. Now I created a fresh workspace and defined a target platform to point to the installed product on my disc. Next I created a sample bundle and an Eclipse application launch configuration. I selected the correct application but on the "Plug-ins" tab I configured "Launch with: all workspace and enabled target plug-ins". However, PDE is unable to launch the application because the application service is not available. Inspecting the created configuration I noticed that the start level for org.eclipse.equinox.app is not correctly set in bundle.info. It's at level 4 with no auto-start set. But in the target platform it's at level 3 with auto-start set. Thus, I think PDE does not correctly read the bundle.info from the target platform. I also re-configured the target platform to point to the generated p2 repository but this did not help either.
Created attachment 170493 [details] patch for starting equinox.app bundle This patch ensures that org.eclipse.equinox.app bundle is started. I also created a constant for the bundle name.
This should be a 3.6.1 candidate. PDE Team please remove target milestone if you think it shouldn't.
Created attachment 171263 [details] smaller patch This is a potential candidate. However, in the interest of keeping 3.6.1 fixes as small as possible, I would suggest to use the alternate patch (which is really a one line addition/change).
I'm not familiar with the "org.eclipse.equinox.app" bundle. However, it looks like it's been part of the platform for a while. My concern is that this code will affect all launches, and if so, what would be the side effect of setting the start level of this bundle to 2, when it was historically 4? Tom, can you shed light on this bundle?
(In reply to comment #4) > I'm not familiar with the "org.eclipse.equinox.app" bundle. However, it looks > like it's been part of the platform for a while. My concern is that this code > will affect all launches, and if so, what would be the side effect of setting > the start level of this bundle to 2, when it was historically 4? > > Tom, can you shed light on this bundle? If org.eclipse.core.runtime is configured to start then you should not do anything special for equinox.app. In the case that core.runtime is set to start then you should assume core.runtime will kick the start of equinox.app. equinox.app was created to split the application model of eclipse out of core.runtime. It must be set to start in the absence of core.runtime. So I don't think the simple patch is appropriate.
(In reply to comment #5) > equinox.app was created to split the application model of eclipse out of > core.runtime. It must be set to start in the absence of core.runtime. So I > don't think the simple patch is appropriate. Why not? You already mentioned the reason that core.runtime is absence. To run Eclipse applications one doesn't need core.runtime. I think PDE should support this.
(In reply to comment #6) > (In reply to comment #5) > > equinox.app was created to split the application model of eclipse out of > > core.runtime. It must be set to start in the absence of core.runtime. So I > > don't think the simple patch is appropriate. > > Why not? You already mentioned the reason that core.runtime is absence. To run > Eclipse applications one doesn't need core.runtime. I think PDE should support > this. I don't have the full context of the patch. Does it only set the start level of equinox.app if core.runtime is NOT marked for start? I am against marking equinox.app for start at an early start-level if core.runtime is marked for start.
(In reply to comment #7) > I don't have the full context of the patch. Does it only set the start level > of equinox.app if core.runtime is NOT marked for start? I am against marking > equinox.app for start at an early start-level if core.runtime is marked for > start. Ah ok. So then the patch needs a bit rework to set a start level for equinox.app only if core.runtime is not present in the launch profile.
Created attachment 175370 [details] patch to start equinox.app only if core.runtime is not present I updated the patch to only set start level for equinox.app bundle if core.runtime is not present. I also updated the start level to "default" instead of "2" to align it with core.runtime.
The latest patch is only looking at whether PDE has a model for core runtime. If a launch config has disabled core runtime, the start level of equinox app will not be updated. That being said, the fix would cover cases where people have a target without core runtime. Moving to 3.7, this is not a regression and we don't have a good fix.
Created attachment 183218 [details] patch to start equinox.app if core.runtime is not present This is an update of the patch against the current HEAD. Can you please consider this for inclusion into 3.7 M4?
what is the relationship with .product files? I'm not keen on more disconnects between whatyou can do in a .launch and a .product. I'm all for lowering the barrier etc but would like to do so consistently.
(In reply to comment #12) > what is the relationship with .product files? There is not really a relation to .product files directly. When you have a .product file you spec start levels in there directly. This patch addresses an issue when you have a headless target platform based on a downloaded pre-build product that comes without core.runtime. Currently, the Eclipse Application launch config does some magic in order to read start levels from the target platform and automatically start required bundles for Equinox to work correctly. However, it does so by scanning the list of available bundles for core.runtime and just set it's default auto-start to true in order to have the application service available for starting an application. Otherwise the Eclipse Application launch fails. But core.runtime is not the right bundle IMHO. It's necessary for backwards compatibility. The application service is in equinox.app. Therefore this must be started in order to launch an Eclipse application. Experienced users may know this. But PDE should be smart and aid the non-experienced users (IMO).
understood and agreed. I'm thinking though that the same user shoudl have the same experience whether using a launch config or a .product. a .product after all just ends up generating an Eclipse launch config. It's not good to get different behaviours. I'm not particular as to which behavior we get but would like them to be the same.
I see your point. The current implementation contains a lot of those smart workarounds already. Thus, today a launch is not exactly the launch represented in a .product file. Some checks would need to put in place in order to disable this behavior and rely on the .product file only. In such a case, I wonder if the product editor needs to be enhanced in order to warn users about missing bundles that should/must be started? Otherwise a launch would fail.
yes, I'd like to see a warning in the .product editor that says, you've said you want to run an application but the .app bundle is not being started. Related to comment 10, is PluginRegistry.findModel(IPDEBuildConstants.BUNDLE_CORE_RUNTIME) enough? The runtime might be in there target but not included in the launch so the problem is still there.
Bumping to 3.8 due to lack of resources.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
