Community
Participate
Working Groups
AFAIK we do not an option to update the target platform automatically at startup. It currently seems to work in a strange way: If the target editor is open (either visible or not) an update of the target platform is triggered. I think that is confusing and should be replaces with a better approach. Ideally the reload would only be triggered if the target file changes.
(In reply to Lars Vogel from comment #0) > AFAIK we do not an option to update the target platform automatically at > startup. I think the idea is that (once I have set the target) I can restart eclipse without having to go through the resolving and all these potentially lengthy tasks. > > It currently seems to work in a strange way: If the target editor is open > (either visible or not) an update of the target platform is triggered. I also noticed that and this is really not desirable (see above) e.g. without an internet-connection one could mess up the current workspace. > I think that is confusing and should be replaces with a better approach. > Ideally the reload would only be triggered if the target file changes. We had this discussion at tycho already and looking at the target file is not sufficient because depending on the configuration the content of a target can change without the target file itself is changed (e.g. 0.0.0 Versions, directory targets, custom target types...)
(In reply to Christoph Laeubrich from comment #1) > I also noticed that and this is really not desirable (see above) e.g. > without an internet-connection one could mess up the current workspace. +1, as soon as we have this preference setting via this bug, I would suggest to remove this auto-update of the target platform "only" because the editor is open. I think deleting line 95 (setActiveEditor(this); ) in the target editor would remove this "functionality". As some clients may use this feature to update their target platform, I think we first need to add a update option via the preferences. > > I think that is confusing and should be replaces with a better approach. > > Ideally the reload would only be triggered if the target file changes. > > We had this discussion at tycho already and looking at the target file is > not sufficient because depending on the configuration the content of a > target can change without the target file itself is changed (e.g. 0.0.0 > Versions, directory targets, custom target types...) Make sense but this could also be an option (Only if target content changes / Always refresh).
I think the target should only ever be updated if I actively press "Set as active Target". For sure if PDE detects any change (aka file change) because of git update or something it could kindly ask if I like to refresh/update the current target ;-)
(In reply to Christoph Laeubrich from comment #3) > For sure if PDE detects any change (aka file change) because of git update > or something it could kindly ask if I like to refresh/update the current > target ;-) Do we already have a change listener on the current target definition?
The points you have discussed so far a definitely things that should be addressed. The Target-Platform should only be refreshed/reloaded/updated if asked to do so for the reasons you have mentioned. What I want to add is that when it is reloaded (e.g. through the "Reload Target Platform" action in the Target-Editors source tab) it should be really 'fully' reloaded. I (and my colleges as well) frequently have the situation that after reloading my workspace is fully of errors because bundles cannot be resolved. Restarting Eclipse often solves those errors (but it is annoying to be forced to often restart Eclipse). I have not yet found out what's exactly the issue but I assume that something inside PDE is not properly updated. What also seems to perform a 'deeper' reload is opening a target in the preferences-page via the 'Edit' button. But it would be really nice if PDE just restores is state when Eclipse is started leaves the target-platform untouched and only update/reloads it when commanded to do so (if PDE detects changes it would of course be good to suggest the user a reload). But then a reload should be 'complete' and only necessary once. If it takes a little longer it is OK in my opinion. I would rather wait five minutes after one click (and drink a coffee) than have to go through a sequence of multiple Eclipse-restarts, target-platform reloads and workspace rebuilds until my workspace is error-free. In the end this probably takes as long or even longer as a 'complete' reload and is just much more annoying. I have not yet looked into the details why PDE behaves exactly as described (maybe it also interferes with the XText-builder which we are often using), but I'm willing to do so and to improve PDE in this regard.
(In reply to Hannes Wellmann from comment #5) > The points you have discussed so far a definitely things that should be > addressed. The Target-Platform should only be refreshed/reloaded/updated if > asked to do so for the reasons you have mentioned. > > What I want to add is that when it is reloaded (e.g. through the "Reload > Target Platform" action in the Target-Editors source tab) it should be > really 'fully' reloaded. I (and my colleges as well) frequently have the > situation that after reloading my workspace is fully of errors because > bundles cannot be resolved. Restarting Eclipse often solves those errors > (but it is annoying to be forced to often restart Eclipse). I have not yet > found out what's exactly the issue but I assume that something inside PDE is > not properly updated. What also seems to perform a 'deeper' reload is > opening a target in the preferences-page via the 'Edit' button. Would be nice if any reload does the same thing. > But it would be really nice if PDE just restores is state when Eclipse is > started leaves the target-platform untouched and only update/reloads it when > commanded to do so (if PDE detects changes it would of course be good to > suggest the user a reload). But then a reload should be 'complete' and only > necessary once. +1 > If it takes a little longer it is OK in my opinion. I would > rather wait five minutes after one click (and drink a coffee) than have to > go through a sequence of multiple Eclipse-restarts, target-platform reloads > and workspace rebuilds until my workspace is error-free. In the end this > probably takes as long or even longer as a 'complete' reload and is just > much more annoying. +1, the current behavior is super annoying. > I have not yet looked into the details why PDE behaves exactly as described > (maybe it also interferes with the XText-builder which we are often using), > but I'm willing to do so and to improve PDE in this regard. Thanks, that would be great. FYI I see the same weird behavior without xText.
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.
