Community
Participate
Working Groups
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.
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.
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.
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?
(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.
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
Created attachment 174999 [details] patch with test for 3.6.1 maintenance branch
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.
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'?
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.
Wow, that was fast! Darin, thanks a lot for this speedy analysis and workaround.
As one of the developers suffering the problems JM mentioned, I can attest that Darin's workaround in comment 9 works.
Released to 3.6.1. Fixed. Please verify, Curtis.
Also released to 3.7 (HEAD)
Verified
Verified in I20100804-0100 (3.7)
*** Bug 324293 has been marked as a duplicate of this bug. ***
Verified in M20100901-1310
I am still seeing this with 3.7 M2. I will send the target platform I am seeing this with to Darin Wright.
(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.
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.
(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.
created https://bugs.eclipse.org/bugs/show_bug.cgi?id=327136
