Community
Participate
Working Groups
As a newcomer to eclipse, this aspect of the plug-in editor was not at all clear. Seeing an "Activate this plug-in when one its classes is loaded" checkbox, my immediate thought was that the alternative was "Don't activate this plug-in when one its classes is loaded". Ie don't call any activator class. My initial assumption was that the checkbox was enabling the use of the activator field immediately above, or something along those lines. It took a while to realise that this checkbox was the "lazy start" option. Wording like "Don't activate this plug-in until one of its classes is loaded" or "Only activate this plug-in when one of its classes is loaded" would be much, much clearer.
Wording is indeed a challenge here. the bundle activator can be called explicitly by someone or implicitly by the system (if this option is enabled). The current wording takes the positive active voice approach of enabling automatic activation on classloading. It does not preclude activation by other means. Disabling this feature limits activation to other mechansism. The suggested wording takes a negative approach which is much harder to manage. Both wordings imply that if the option is deselected, activation will never happen under any circumstances. This is behaviour is not at all supported by the OSGi spec. Someone with sufficient permissions can always call Bundle.start(). By analogy, if you "enable automatic updates" in your operating system you are saying you want the system to help you out. If you disable this option it does not follow that updating is not possible, just that it is not done automatically for you. Having said all that, it would be great to improve the wording. Other suggestions?
Presumably it was felt that "lazy start" was a bit too jargon and/or informal. Yet it does have the advantage of being appropriately non-specific about when activation happens. If we can't be concrete about that mode, we can at least be concrete about the opposite. How about reversing the button and making it "Activate this plug-in immediately on platform start-up" The presence of "immediately" hopefully tries to convey the sense of what the opposite is. It doesn't give you a clue as to when it will be activated if disabled, but then maybe that's a good thing. It's logical to assume it will be activated when needed, and it should occur to people to check the documentation. Still not totally happy with that though. Do you think there's a general argument for reversing the button sense? Lazy start is felt to be the preferred mode of operation, as far as I'm aware, so may be it should be the unticked option in the GUI, even if it isn't in the Manifest file. Alternatively, at the cost of screen space, you could go for a pair of radio buttons: "Activate this plug-in immediately on platform start-up" "Activate this plug-in when one of its classes is loaded" I quite like that for clarity, but it would be better if we could come up with something in one line. I'll ponder further. A semi-cop-out would be to stick a little tip icon next to the button leading to pop-up help like you get in the extension point editor from the schema description.
We actually currently do not support an "immediate start" mode nor is this detailed in the spec. The default behaviour is to not activate a bundle unless "someone" explicitly requests. In traditional OSGi environments it was always assumed that htere would be some sort of "management agent/administrator" around that would know which bundles to start and when. In Eclipse this is not generally the case. To support backward compatibility when we moved to OSGi in 3.0 and to mitigate the burden on the agent/administrator (read end-user in the Eclipse world) we added the lazy start behavoviour. Subsequently that has been included in the OSGi spec. So in effect, the framework itself can act as the activation agent in the case of lazy start bundles. So much for context/history. Notice that the notion of immediate or agressive starting has not been raised in the above discussion. the underlying markup admits the possibility of such a setting but in CPEG conversations it was explicitly decided to not include that as the bundle developer is not in a position to say that their bundle should be agressively started in all situations (as would be implied by a manifest settting). BTW, the best option is for no actiation to be required at all. We have always pushed for people not to require startup in their bundles and that if they did, it should be done lazily.
Really? Is it the case that even though I thought I'd overcome my initial misunderstandings, I still had it wrong? I'd concluded that if the option was off, the bundle gets activated by Eclipse during start up. I've double-checked the help section "OSGi Bundle Manifest Headers" and that still seems to me to imply that if Eclipse-LazyStart isn't set then Eclipse activates the bundle on start-up (although it doesn't say it explicitly): "The Eclipse-LazyStart header is used to specify if a bundle should be started before the first class or resource is accessed from that bundle. This feature allows Eclipse to activate bundles lazily the first time they are needed. Using this model Eclipse can startup with as few active bundles as possible." I've read the OSGi spec now, so (I hope) I understand the relationship between Bundle.start(), activation and lazy start. Are you saying that with the option not set, the Eclipse platform won't call Bundle.start() at all? If so, then my very first understanding of the option was correct. Or are you saying that it will call Bundle.start(), but not at platform start-up? I'd concluded that Eclipse called Bundle.start() on all plug-ins at start up, and Lazy-Start deferred the actual activation call. This is beginning to feel like it should be a newsgroup discussion, but I guess I'm an example of the built-in help not doing its job. Truly, the built-in help isn't clear on this. And I've noticed that the PDE editor help totally fails to mention the button at all.
Really really. No free starting other than the lazy start support. Note: for completeness I will point out that using the @start notation in the config.ini can cause bundles to be agressively started but that is not at all common. Note also the ability to explicitly control bundle starting in the launch OSGi launch configs is another hint that autostarting is not the normal case The help is correct though perhaps not entirely clear on the matter. from your quoted bit "Using this model Eclipse can startup with as few active bundles as possible." This option is in place because some bundles need to be started. If the option was not in place then all bundles would have to be activated "just in case". I can accept that the doc is not crystal clear on this and will suggest that this be turned into a [doc] bug unless there is something to be done in the code.
I can understand the confusion. The activation policies have always been challenging to word accurately :) Since we cannot explain the entire purpose of the check box, I was going to suggest you use F1 help to fully understand its purpose. When I triggered F1 and clicked on the Plug-in Overview link, I noticed there is no documentation on the check box. So I agree with Jeff (for the second time today), that this should become a doc bug. Whenever you have questions about anything in the UI, you should be able to use F1 help to get additional information on it. It seems that PDE is lacking in this case.
adding documentation keyword
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.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
