Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357211 - CVS preferences busted in N-builds
Summary: CVS preferences busted in N-builds
Status: CLOSED DUPLICATE of bug 356306
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.8   Edit
Hardware: PC Windows 7
: P3 major (vote)
Target Milestone: 3.8 M2   Edit
Assignee: platform-runtime-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-09 06:49 EDT by Markus Keller CLA
Modified: 2011-09-13 01:52 EDT (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2011-09-12 09:40:03 EDT 
Moving to Platform/Runtime, see comment 5.
Comment 8 Tomasz Zarna CLA 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 CLA 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 CLA 2011-09-13 01:52:40 EDT 
Verified in I20110912-2126 that the bug is fixed.