Community
Participate
Working Groups
Extension point org.eclipse.ui.quickAccess allows to add QuickAccessProviders. However, this will activate the host bundle, which -in some cases- may not be desired. When the bundle is already activated, then it's all fine invoking the provider; in cases it's not activated, extenders should be able to provide some "activeWhen" condition or similar to declare whether the provider should be loaded.
I believe we had something similar in common navigator. Was just an attribute in xml AFAIR, not a condition.
Do we really need a flag? Or we simply will not load extensions from not yet activated bundles? Because let assume 3rd party bundle wants to contribute to QA and only to that. It would be activated only if it contribution is loaded, so it will always set the flag to activate. So flag alone will not be enough. But which condition should such a bundle provide? Always activate me, because I'm important one?
(In reply to Andrey Loskutov from comment #2) > Do we really need a flag? Or we simply will not load extensions from not yet > activated bundles? Right, we don't need a flag at the moment. Especially since early startup can be triggered in many different ways (like an IStartup) so adding one extra control doesn't seem relevant.
That said, I've spent an hour looking at the code, and this won't be trivial as it relies a lot on the assumption that the QuickAccessProvider is available early enough. I think we'll need to change a bit the extension point.
New Gerrit change created: https://git.eclipse.org/r/141667
@Dani: this proposal heavily modifies the extension point and API that were introduced in previous milestone, for good value IMO. Is it fine to merge it since it was not in a release?
(In reply to Mickael Istria from comment #6) > @Dani: this proposal heavily modifies the extension point and API that were > introduced in previous milestone, for good value IMO. Is it fine to merge it > since it was not in a release? Yes, that's fine with me.
Gerrit change https://git.eclipse.org/r/141667 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b185256c735d863079e384ceeb0b771960dc6c65
(In reply to Eclipse Genie from comment #8) > Gerrit change https://git.eclipse.org/r/141667 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=b185256c735d863079e384ceeb0b771960dc6c65 This caused lot of API errors in org.eclipse.ui.workbench, because minor segment on org.eclipse.ui.workbench version was increased *second time* in the 4.12 release. @Mickael: please install API tools if you change API and make sure you have right baseline. Please fix new API errors.
(In reply to Andrey Loskutov from comment #9) > (In reply to Eclipse Genie from comment #8) > > Gerrit change https://git.eclipse.org/r/141667 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=b185256c735d863079e384ceeb0b771960dc6c65 > > This caused lot of API errors in org.eclipse.ui.workbench, because minor > segment on org.eclipse.ui.workbench version was increased *second time* in > the 4.12 release. > > @Mickael: please install API tools if you change API and make sure you have > right baseline. Please fix new API errors. How many times do we have to tell this?
The reason is that some other patch did erroneously bump the version by +0.0.100, and to ensure now APIs can be referenced properly, it was necessary to bump it a second time. (In reply to Dani Megert from comment #10) > (In reply to Andrey Loskutov from comment #9) > > @Mickael: please install API tools if you change API and make sure you have > > right baseline. Please fix new API errors. > How many times do we have to tell this? Whenever I start API Tools, I have to disable it after a few hours because they make my workspace too slow to build and not usable. I cannot work efficiently with them installed. IMO, since API checks are a quality gate, they have to be automated as part of the build and make build fail in case of error. That would make things simpler for everyone.
(In reply to Mickael Istria from comment #11) > The reason is that some other patch did erroneously bump the version by > +0.0.100, and to ensure now APIs can be referenced properly, it was > necessary to bump it a second time. OMG I see. > Whenever I start API Tools, I have to disable it after a few hours because > they make my workspace too slow to build and not usable. I cannot work > efficiently with them installed. > IMO, since API checks are a quality gate, they have to be automated as part > of the build and make build fail in case of error. That would make things > simpler for everyone. As long as this is not implemented you *have to* install and use API tools. I have them always on and I can work without disturbing others. Please either contribute your automated check or do the same. I can't always do the dirty work for others.
(In reply to Andrey Loskutov from comment #12) > As long as this is not implemented you *have to* install and use API tools. > I have them always on and I can work without disturbing others. Please > either contribute your automated check or do the same. I can't always do the > dirty work for others. +1!
So in this case, is the best approach to create API Filters, or is there something better we can do about versioning?
New Gerrit change created: https://git.eclipse.org/r/141806
(In reply to Mickael Istria from comment #14) > So in this case, is the best approach to create API Filters, or is there > something better we can do about versioning? (In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/141806 That is what I would do.
Gerrit change https://git.eclipse.org/r/141806 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=667c6d7e6e94faffc104ffafbf0e244e25923de9
Thanks Andrey.
