Community
Participate
Working Groups
If you have a baseline version of Eclipse set up and you update that version - same location on-disk, but the bundles are updated - the baseline does not seem to refresh. An example of this was Curtis updated his version of 4.2.2 to he also used as a baseline and there were invalid since tags reported on some of the platform UI bundles. Only after much fiddling and refreshing did he manage to get the baseline (in API tools) updated correctly and the errors went away. It would be good if we could either just always make sure the baseline stays in the correct sync-state or warn the user that the baseline is out of sync. Personally I would rather just always try to keep it in sync (no warnings) and only warn if something fatal has happened and the baseline is no longer usable.
This is the similar to what occurs with PDE Target Definitions. If the content changes we cannot recognize it until the the target platform is reset. We added a synchronize button to the preference page that resolves the current definition and compares it to the current platform. If there is a different a dialog pops up to notify the user and and pressing ok/apply on the preference page will force a target platform reset.
Created attachment 229649 [details] Example fix This patch adds a job that runs when the preference page is opened. If the number of components at the default baseline location have changed, it sets the page to dirty and adds a warning message. This is reasonably unintrusive, though a user quickly skipping through preference pages might get asked to do a workspace rebuild without knowing why. In the target platform the user must hit a button to start the process, which could easily be implemented here. Checking that no component name/versions have changes will require a lot more effort as doing so requires manifest loading (though we do this for the labels in the edit dialog). Doing this in the background during startup seems wasteful as well because the baseline isn't going to change very often.
(In reply to comment #2) Couldn't you check the baseline the first time the API builder needs them? You could then simply report this as error, like the missing base line error.
It appears comparing the component count is not sufficient. Without loading the manifests we don't know that some of the bundles are source bundles (which are ignored), leading to different counts. 1) The baseline cache persisted between sessions remembers the locations of all the components, so checking that all those locations still exist would be reasonably fast. The problem there is that performing an update on an application may not garbage collect the old bundles. 2) Checking that the list matches what is returned when loading the baseline location would be slower (as the target resolution code loads manifest files). 3) The slowest option is to reload the baseline entirely, but would obviously catch any problems. (In reply to comment #3) > (In reply to comment #2) > > Couldn't you check the baseline the first time the API builder needs them? > You could then simply report this as error, like the missing base line error. Yes, we could check it at this time, but of course comes with a performance cost. While the time heavily depends on I/O speed, for an SDK, option (1) takes < 2s, (2) takes < 5s, (3) takes 5-10s.
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.
Vikas, please check whether this is still relevant.
I will have a look at this for 4.13.
Created attachment 279430 [details] Example fix wrt current code base
(In reply to Vikas Chandra from comment #8) > Created attachment 279430 [details] > Example fix wrt current code base There are few open issues ( comment#4) - Checking the versions could be 1 way ( fast and effective) - Also it must be once only when API Analysis builder is initialized( comment#3)
(In reply to Vikas Chandra from comment #9) > (In reply to Vikas Chandra from comment #8) > > Created attachment 279430 [details] > > Example fix wrt current code base > > There are few open issues ( comment#4) > > - Checking the versions could be 1 way ( fast and effective) > - Also it must be once only when API Analysis builder is initialized( > comment#3) Moving to 4.14
