This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It's request for (almost) reverse process. I need to remove beta API from stable release. Please judge if this sort of problems should undergo a kind of ARCH process. If so then please review <http://tasklist.netbeans.org/proposals/barracuda/api-stability.txt> (the proposal) and approve or disapprove the proposed solution. Thank you
Petr, is there any summary of what the APIs do and what other modules use them or will have to use them? That would be helpful for thinking about your proposal. Thanks.
In short the framework is built around Suggestion (and SuggestionManager) class. Modules can create suggestions as side effect of their computations and push them to the manager or register themself (as providers) with the framework to get pull suggestion retrieval queries. All modules can provide suggestions. The pull approach sometimes overlaps with currently used check&fix actions/wizards. The difference is in workflow (assuming current implementation). Right now it's used by all tasklist submodules. There is also one known fork attempt by external developer.
Sound like the change is not too controversial and we can go for fast track review. Petre, please announce it to nbdev to double check if anybody was using the current API. My opinion is that the proposed solution (option B) is the best we can do.
Drawback of B is that we will not have good answer to any 3rd party contributor trying to plug into the tasklist. Answer "there is no api" is not too satisfying, answer "you have to have impl dependency" is a bit better, but still, we should support an attempt to write nonstable API module and publish it on autoupdate. If used by other only-autoupdate tasklist modules (I understand that there are few not going to be stable), the quality would be guaranteed (e.g. it would be useful) and would probably have a better chance to become the real api (at least it would be in the right packages).
I really do not want to support both internal API accessed using implementation dependencies and unstable API. I do not see any real advantage. Non-stable modules can use implementation dependency. Such modules are under development so they can accomodate to both new API or implementation change without loosing any mayor investments. From stable modules point of view API matters but they need only stable API (I guess author will favour implementation dependency on stable implementation version over dependning on unstable API).
I think that if Petr does not have time to create good and stable API (option A) it's better not to create any API. IMO rushing with APIs will not be any useful. The usefulness of unstable API can be tested just as well with implementation dependency. Having the correct packages is worse, not better, since it blurs the boundary between stable API and nonstable implementation code.
Removed, module renamed to org.netbeans.tasklistapi.
I read "B) Remove the API completely" as "B) Do not attempt to have stable API" as inside this task is written: - repackage api to org.netbeans.modules.tasklist.clients - repackage spi to org.netbeans.modules.tasklist.providers - rename the module (there are the beta versions living around) - set Public-Packages attribute to '-' - force maintainers to establish tasklist-barracuda impl dependency which indicates that there is an API. Then I think: Its stability should be specified, and probably javadoc released which people should treat as a stable as the stability category says. Imho, if want to make the API stable someday, you have to advertise it. And release under less than stable category seems to be the right option.
What is wrong with this issue? It is still listed as open fast track request. Turning into something that is being tracked (p2 defect) so the module owner has to act.
I believe that B) (i.e. what Peter has already done) is the right solution for the time being. The current "api" is not only unstable, but far from complete. Unfortunatelly, we don't currently have time to redesign the apis. The only feasible solution thus is hiding the current "api" for the time being and publishing stable and complete api later, when there's time and demand for it. Closing as fixed, as the APIs are removed as requested by this issue.