Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Check for "branding" plugin if splash plugin not specified, and add fragments | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Kenneth Evans, Jr. <evans> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | irbull, ken, pascal | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Kenneth Evans, Jr.
This is working fine for me in 3.6 head. Make sure the product file lists a plugin containing the splash.bmp on the splash tab. In the exported application does the config.ini have osgi.splashPath? It uses "Generate a default config.ini". The plug-in with splash.bmp is there. The fact that I get a splash screen with "Generate metadata repository" unchecked indicates it is set up OK in both these regards. Thanks, -Ken I apologize for not actually checking config.ini. The answer is that the "osgi.splashPath=" line is _not_ there. If I add it manually, then the splash screen appears. Thus, the problem is that the logic that does "Generate a default config.ini" is wrong when using p2. This gives me workaround at least. Thanks. >> This gives me workaround at least.
I thought I could specify a config.ini file in the Configuration tab of the .product editor by using "Use an existing config.ini file". I used the one that it generated automatically before with the additional line for the "osgi.splashPath=". However, it doesn't use mine and generates a new one without the "osgi.splashPath=" line (hence no splash screen).
I don't understand what is happening. There are no error messages that I can see. Perhaps this is another error in the config file logic?
I verified this problem is still happening with 3.6.0 M7. Ken, can you attach your example project that does this so I can try exporting it. Andrew, Thanks for looking at it. I will attach a ZIP with two projects that are based on com.example.mail with as few changes as possible from the wizard. When deploying: 1. With "Generate a meta repository" unchecked, there is a splash screen and config.ini has osgi.splashPath in it. 2. With it checked there is no splash and osgi.splashPath does not appear. 3. Using the generated config.ini from 1. and setting the Configure tab to use it, there is still no splash screen or osgi.splashPath. (This is the current state of the project). I get the same results with another, slightly more complicated project of my own. -Ken Created attachment 168820 [details]
ZIP file with two com.example.mail attachments.
The .product file does not specify the bundle which contains the splash bitmap. See the splash tab of the product editor. If you specify the splash plugin there things work fine. It turns out that when not doing a p2 install, pde.build will look for a "branding" plugin for the product if the splash plugin is not specified. The branding plugin is the product id with the last segment removed (org.example.mail.product -> org.example.mail). PDE/Build will also check for fragments of the plugin and add them to the splashPath as well. In the case of a p2 install, the publisher is responsible for generating the osgi.splashPath metadata. The publisher will need to be updated to do this extra work. The publisher does not have access to the osgi state that pde/build uses in this case, and will need to do this work by running queries on the available repos. This seems like a bit too much in RC2 given that there is a simple workaround of just specifying the splash bundle in the .product file. We can look in 3.6.1 Regarding the config.ini, the attached mail.product file is not using it. If I edit the .product file to use the config.ini, then the export product will show the splash screen, but quickly exit with an error since when a config.ini is specified, export no longer generates the default config settings and the prodvided config.ini does not give any start levels. Andrew, >> If you specify the splash plugin there things work fine. Thanks for the workaround. As much time as I've spent on this, I should have run across that myself and tried it. In my defense, in years of writing plug-ins I have never had to do that. That at least solves my immediate problem. And it works in 3.5.1 also. Seems like it should be fixed eventually, though, as you mentioned. >> Regarding the config.ini, the attached mail.product file is not using it. Sorry about that. I had done both ways many times. Apparently what was in the ZIP was without using the config.ini (which is in the project). Before the change above, it did not give an error to use it, but also did not _use_ it, instead generating an automatic one. This seems like a problem in itself. It is nice that you understand why there is _now_ an error message. From the error message that results, I would have a hard time figuring that out: !ENTRY org.eclipse.osgi 4 0 2010-05-18 14:47:17.255 !MESSAGE Application error !STACK 1 java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini). at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) The config.ini in error that it says to look at seems to be the same as the one generated when not using the default config.ini _and_ not checking "Generate metadata repository" (and _not specifying the splash plug-in). The config.ini in the project is one of these. I am confused. Are these the results you get when using the config.ini in the project I sent (under these various conditions, use/not use, specify/not specify, check/not check)? Thanks for your help. -Ken (In reply to comment #10) > java.lang.IllegalStateException: Unable to acquire application service. Ensure > that the org.eclipse.core.runtime bundle is resolved and started (see > config.ini). > The config.ini in error that it says to look at seems to be the same as the one > generated when not using the default config.ini _and_ not checking "Generate > metadata repository" (and _not specifying the splash plug-in). The config.ini > in the project is one of these. I am confused. > > Are these the results you get when using the config.ini in the project I sent > (under these various conditions, use/not use, specify/not specify, check/not > check)? > Yes, these are the same results. The problem is that we are missing start level information. The config.ini generated as a default uses the simpleconfigurator, and as such does not specify the start levels for any other bundles, that information is in the bundles.info file: osgi.bundles=org.eclipse.equinox.simpleconfigurator@1:start org.eclipse.equinox.simpleconfigurator.configUrl=file:org.eclipse.equinox.simpleconfigurator/bundles.info You can add "org.eclipse.equinox.simpleconfigurator/bundles.info" to your project so that it can be found relative to the config.ini file. However, I found bug 313625, you will need to specify the location of the config.ini file as an absolute path in the .product file. I also found Bug 313627 Andrew, In another simple example with the same problem I specify the start levels in the .product configuration. (I don't think I should have to do this, but I do. See #312806 ;-). It is only needed to implement dropins. This example has the same problem with the splash and the non-default config.ini as the com.mail.example I sent. Thus, I don't think it is related to start levels. The default config.ini for the other example only has: osgi.bundles.defaultStartLevel=4 as does this one. There seem (to me) to be problems with generating a non-default config.ini with p2. You are in a better position to understand that issue than I. I have little experience in doing that as it is hardly ever necessary (which is good ;-). The one time I did do it, the config.ini became not working over time owing to changes in the platform and was a nuisance to manage. It was only done, as in this case, as a workaround for another problem that was eventually fixed. In any event, specifying the splash plug-in in the .product Splash tab, solves my problem and I don't need the non-default config.ini. You can decide if the non-default config.ini issues are a problem. (And thanks for the tip ;-) In regard to specifying the splash plug-in, it seems to me that the p2 deployment could just assume the splash screen is in the defining plug-in for the .product rather than use the mechanism with the publisher you mentioned. I would assume that is what is done without p2, since I have never specified the splash plug-in. If you don't want a splash screen, you can use -nosplash, so this assumption doesn't cause problems and replicates past behavior. From my perspective (which is from pretty far away ;-) it seems like the p2 team and the PDE team need to interact some more. I could be wrong and don't mean to be critical. It will all work sometime. Thanks for your help, -Ken Moving to inbox 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. From my point of view as the originator of the issue it can be closed. It is so old that I have no memory of the details of the issue. I probably solved the problem for myself by using the workaround. |