Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 341579

Summary:	Wrong splash screen shown when configuration is readonly
Product:	[Eclipse Project] Equinox	Reporter:	Tom Quarendon <tomq>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	prakash, tjwatson
Version:	3.6.1
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:	stalebug

Description Tom Quarendon

2011-04-01 04:10:07 EDT

Build Identifier: 3.6.1 helios

Eclipse 3.6.1 on Linux

I have an eclipse based product, but it seems that whenever I try and set up a multi-user install, once the config.ini has been written to a different place the branding goes away.

If I take a vanilla "eclipse platform" install, add my plugins and features, then modify the config.ini file to change the "eclipse.product" and "osgi.splashPath" and then start eclipse, the product comes up correctly. I get the right splash screen, the right perspective comes up etc.

I then close down eclipse, and look at the rewritten config.ini file in the eclipse/configuration directory. It all seems as I expect, and still has my eclipse.product and osgi.splashPath in (I can tell from the timestamp at the top that it's just been rewritten by eclipse closing). Restarting eclipse then still has the same branding.

I then repeat the whole process, but this time make the eclipse installation directory readonly. First time it comes up fine, using the now readonly config.ini file. I then close down eclipse, forcing it to rewrite the config.ini file into my ~/.eclipse/.../configuration/config.ini directory. If I then look at the generated config.ini file I find that the eclipse.product and osgi.splashPath properties have reverted to default values, org.eclipse.platform.ide and platform\:/base/plugins/org.eclipse.platform. Then when I restart eclipse I get the default eclipse splash, rather than my product's splash. The same happens if I don't make the eclipse directory readonly, but instead set an explicit osgi.configuration.area property in the config.ini.

So as far as I can tell the multi-user install support doesn't seem to work properly with eclipse based products.

Is this a known problem with a known solution? Or am I doing something wrong in my set up that is causing this.

Reproducible: Always

Steps to Reproduce:
1. Take vanilla eclipse, and a product with some branding and splash screen. Edit config.ini so that it references your branded product
2. Make eclipse installation readonly
3. start eclipse
4. Stop eclipse. Writes new config.ini file to your home directory
5. start eclipse. You'll get default eclipse splash because rewritten config.ini file has wrong product referenced in it.

Comment 1 Prakash Rangaraj

2011-04-15 01:30:18 EDT

(In reply to comment #0)
> Steps to Reproduce:
> 1. Take vanilla eclipse, and a product with some branding and splash screen.
> Edit config.ini so that it references your branded product

      So you have a product configuration, but you are not creating the product?

I guess its the Equinox launcher that handles the config.ini file. Moving the bug

Comment 2 Tom Quarendon

2011-04-15 03:44:25 EDT

Not sure I understand the comment.
I believe that I've followed the instructions in the eclipse help about creating a product, but they aren't the most straightforward to understand I don't think.
Any help on this would be good. Gave it to the most appropriate product I could in bugzilla.

Comment 3 Thomas Watson

2011-04-15 08:46:28 EDT

Moving to p2 for advise.  I think this is because the p2 profile for your installation still thinks it is the org.eclipse.platform.ide product and the config.ini written to disk reflects that.

Comment 4 Tom Quarendon

2011-04-15 08:53:03 EDT

Nice email address :-)
I've never understood p2, so quite possible I've not set something up right. there.

Comment 5 Eclipse Genie

2019-11-07 15:17:53 EST

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.