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

Bug 320583

Summary: Target platform gets out of sync at each Eclipse restart
Product: [Eclipse Project] PDE Reporter: Jean-Michel Lemieux <jean-michel_lemieux>
Component: UIAssignee: Darin Wright <darin.eclipse>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: P3 CC: andrew_hoo, andre_weinand, ankur_sharma, benjamin_pasero, curtis.windatt.public, darin.eclipse, evan_hughes, john.camelon, kjdoyle, kresten+eclipse, Mike_Wilson, n.a.edgar, patrick_streule, ralf
Version: 3.6Flags: curtis.windatt.public: review+
darin.eclipse: review+
Target Milestone: 3.6.1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
patch with test for 3.6.1 maintenance branch none

Description Jean-Michel Lemieux CLA 2010-07-22 00:38:05 EDT
We've adopted a rather aggressive use of target platforms that are p2 based and the use of target definition files. Our process is documented and there is a video overview of how we setup our development environments at

https://jazz.net/wiki/bin/view/Main/DevSetupMain#How_do_I_get_started_writing_and

We've been getting a lot of complaints that the target platform is often out of sync and each restart of Eclipse requires developers to open the target pref page, reload the target, and wait for a complete recompile. 

I know the eclipse team doesn't use this feature much in their day-to-day development, so we may be using code that isn't in the main stream development path. But for us, this is critical to scaling our development environments in the face of large projects in which we don't work with source in our workspaces and can't use the client as the target.

I also haven't tried to reproduce with a smaller dataset yet, as a suspect it may have something to do with the size of the code base. I'd be willing to help someone setup a debug environment based on our instructions if that would help, as it's easy to reproduce with our setup.
Comment 1 Ankur Sharma CLA 2010-07-22 08:39:46 EDT
I have setup the RTC 3.0 M7a over Eclipse 3.6 as shown in the video. Need
further instructions and help in setting up the workspace.
Comment 2 Curtis Windatt CLA 2010-07-22 09:07:35 EDT
Darin is also trying to recreate the setup.  Ankur, can you ping us when you want to look at it.  We might be best off setting up a call to go through it.
Comment 3 Darin Wright CLA 2010-07-22 09:42:40 EDT
Can you give more details about the "out of synch" behavior. How does a developer notice this - are there compile errors? are there bundles missing from the target? are there errors in the "Target Platform State" view?
Comment 4 Darin Wright CLA 2010-07-22 10:38:52 EDT
(In reply to comment #3)
> Can you give more details about the "out of synch" behavior. How does a
> developer notice this - are there compile errors? are there bundles missing
> from the target? are there errors in the "Target Platform State" view?

I've answered my own question. After loading the target platform (using a .target definition from Andre) and re-starting, I have compilation errors in two of my projects complaining about build path problems, and the target platform is out of synch when I press "Reload" on the target platform pref page.
Comment 5 Curtis Windatt CLA 2010-07-22 12:18:38 EDT
Definite problem, though it doesn't cause compilation errors in my linux workspace, the target platform is broken (using the target platform state view).  Darin has a possible patch in hand and is working on writing a test case.

Consider for 3.6.1
Comment 6 Darin Wright CLA 2010-07-22 12:56:02 EDT
Created attachment 174999 [details]
patch with test for 3.6.1 maintenance branch
Comment 7 Darin Wright CLA 2010-07-22 12:59:43 EDT
Target restoration was flawed when the "primary" target location (i.e. first entry in the target's locations) referenced PDE's bundle pool (cached/downloaded bundles from p2 update sites to be used in target platforms). One bundle pool is used for all targets and thus bundles have to be restored selectively from the pool. This was done correclty for secondary locations, but not for the primary location. The code was incorrectly using all bundles from the pool when the primary location referenced the pool.
Comment 8 Andrew Hoo CLA 2010-07-22 13:45:26 EDT
Is there a set of workarounds that end users can do until this fix is released? Is there a sure-fire way to clean/reload in a certain order to avoid the problem?

Or, since the bug is in the "primary" target location, will reordering the targets help? Or can we put in a dummy location at the top that will 'take the hit'?
Comment 9 Darin Wright CLA 2010-07-22 15:29:18 EDT
There is a workaround - a bit of a hack. 

I added a primary location that was empty. In order to share an empty location with a team, I added this as the first location in the .target file (since there is no way to order locations from the UI) :

<location path="${eclipse_home}\features" type="Directory"/>

This adds the Eclipse install's features directory to the target, which (at least in my install) has no bundles. Using the variable makes it shareable.
Comment 10 Andre Weinand CLA 2010-07-22 17:02:44 EDT
Wow, that was fast!
Darin, thanks a lot for this speedy analysis and workaround.
Comment 11 Evan Hughes CLA 2010-07-23 10:13:38 EDT
As one of the developers suffering the problems JM mentioned, I can attest that Darin's workaround in comment 9 works.
Comment 12 Darin Wright CLA 2010-07-25 17:14:01 EDT
Released to 3.6.1. Fixed. Please verify, Curtis.
Comment 13 Darin Wright CLA 2010-07-25 17:26:49 EDT
Also released to 3.7 (HEAD)
Comment 14 Curtis Windatt CLA 2010-07-26 12:14:16 EDT
Verified
Comment 15 Darin Wright CLA 2010-08-04 09:24:23 EDT
Verified in I20100804-0100 (3.7)
Comment 16 Darin Wright CLA 2010-09-02 09:44:31 EDT
*** Bug 324293 has been marked as a duplicate of this bug. ***
Comment 17 Darin Wright CLA 2010-09-02 10:05:17 EDT
Verified in M20100901-1310
Comment 18 Benjamin Pasero CLA 2010-10-06 05:23:40 EDT
I am still seeing this with 3.7 M2. I will send the target platform I am seeing this with to Darin Wright.
Comment 19 Darin Wright CLA 2010-10-06 11:42:11 EDT
(In reply to comment #18)
> I am still seeing this with 3.7 M2. I will send the target platform I am seeing
> this with to Darin Wright.

I tried with the target file sent to me and I saw the target platform being out of synch once after the first re-start. On secondary re-start's the target platform seems to remain in synch.

If you have more steps to help reproduce the problem that would be useful. Please open a new bug to track this issue.
Comment 20 Benjamin Pasero CLA 2010-10-06 11:45:34 EDT
Yes I was fixing it myself with a restart. Can't we just reopen this report? Imho it does not make much sense to open a new bug report and loose all the people subscribed here that face the same issue.
Comment 21 Darin Wright CLA 2010-10-06 11:56:08 EDT
(In reply to comment #20)
> Yes I was fixing it myself with a restart. Can't we just reopen this report?
> Imho it does not make much sense to open a new bug report and loose all the
> people subscribed here that face the same issue.

The original problem was that the target was out of synch after *every* re-start. Since the fix to this bug has been shipped in a release, I'd rather open a new bug to track any new work/fixes that need to be addressed.
Comment 22 Benjamin Pasero CLA 2010-10-06 12:38:50 EDT
created https://bugs.eclipse.org/bugs/show_bug.cgi?id=327136