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

Bug 357211

Summary:	CVS preferences busted in N-builds
Product:	[Eclipse Project] Platform	Reporter:	Markus Keller <markus.kell.r>
Component:	Runtime	Assignee:	platform-runtime-inbox <platform-runtime-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	major
Priority:	P3	CC:	daniel_megert, dj.houghton, john.arthorne, remy.suen, tjwatson, tomasz.zarna
Version:	3.8
Target Milestone:	3.8 M2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Markus Keller

2011-09-09 06:49:56 EDT

N20110908-2000 and N20110906-2000, was OK in I20110906-0905

- new workspace
- Preferences > Team > CVS
=> error message "timeout must be a number"
=> on all tabs of that page, preferences are not set

Comment 1 Markus Keller

2011-09-09 06:51:57 EDT

I realized this when I tried to commit and the dialog didn't show any changes (because max files threshold was 0).

Comment 2 Markus Keller

2011-09-09 08:24:48 EDT

This must be investigated before you do the next build input.
Maybe caused by bug 356300 (although that patch looks fine to me)?

Comment 3 Tomasz Zarna

2011-09-12 07:45:01 EDT

After spending some time in the remote debugger (thx for the tip Markus) it turned out that the issing initService is the culprit. It is supposed to be returned by PreferencesOSGiUtils.getDefault().getLegacyPreferences() for "org.eclipse.team.cvs.ui" [1]. If it's not null, eg. when self hosting, the prefs are init'ed properly.

Investigating...

[1] org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(String, WeakReference)

Comment 4 Markus Keller

2011-09-12 08:28:34 EDT

The bug also occurs in I20110911-2000 (where Team didn't contribute).

Looks like a regression in Equinox or maybe a problem with Team relying on compatibility infrastructure without requiring org.eclipse.core.runtime.compatibility.

Comment 5 Tomasz Zarna

2011-09-12 09:22:46 EDT

I patched N20110908-2000 with org.eclipse.core.runtime_3.7.0.v20110110.jar (from I20110906-0905) and the problem is gone. So I think Markus is right suspecting that the culprit is in org.eclipse.core.runtime_3.7.0.v20110831-1452.jar (from  I20110911-2000). For the change that most probably caused this see bug 356306).

Comment 6 Tomasz Zarna

2011-09-12 09:32:50 EDT

(In reply to comment #3)
> If it's not null, eg. when self hosting, the prefs are init'ed properly.

That's because I didn't switch to eclipse.platform.runtime git repo, so I was launching with the source code without the fix from bug 356306. Sync'ing with the CVS repo showed no changes so I thought I'm good.

Comment 7 Tomasz Zarna

2011-09-12 09:40:03 EDT

Moving to Platform/Runtime, see comment 5.

Comment 8 Tomasz Zarna

2011-09-12 11:05:17 EDT

(In reply to comment #5)
> with org.eclipse.core.runtime_3.7.0.v20110110.jar (from I20110906-0905)

org.eclipse.core.runtime_3.7.0.v20110110.jar is not part of I20110906-0905. I looked for a jar older then org.eclipse.core.runtime_3.7.0.v20110831-1452.jar in my bundle pool, saw org.eclipse.core.runtime_3.7.0.v20110110.jar and wrongly assumed that's the jar from I20110906-0905, to which Markus referred as not broken. It's org.eclipse.core.runtime_3.7.0.v20110721-1714.jar that is in I20110906-0905. Sorry for the confusion.

Comment 9 DJ Houghton

2011-09-12 11:07:42 EDT

There is a problem with the timing of registering the services provided by the
runtime bundle, and opening the service trackers used by the bundle.

*** This bug has been marked as a duplicate of bug 356306 ***

Comment 10 Dani Megert

2011-09-13 01:52:40 EDT

Verified in I20110912-2126 that the bug is fixed.