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.
Many developers use or intend to use search functionality for extending NetBeans or in RCP applications. Such a basic functionality should provide a stable API/SPI.
We are now considering deprecating current Search API (org.openidex.search) and creating a new one, that could be stabilized in the near future. What do you think the API should offer? Could you please provide us with some use cases? See bug 207436.
Created attachment 131975 [details] Proposed Patch
Excerpt from email written by Jaroslav Tulach: = %< ================================ I'd like to propose a bit of cleanup. 1. Rename "openidex.search" to "Deprecated, old search API". 2. Rename "api.search" to "Search API" (it does not seem to have project dependency anyway) 3. List the api.search among stable APIs In addition to that I'd suggest a bit of javadoc polishing. Each package should have package.html description. Usecases should use <a href="@TOP@/fqn/Cls.html">Cls</a> to link to real classes. ================================ >% = Fixed in attached patch. Is it OK to keep API SearchProviderUIAPI in category Under Development? (Other APIs in module api.search were marked as Stable.) Is API review needed before making the API stable? Thank you.
Created attachment 131993 [details] Proposed Patch v2 > Is it OK to keep API SearchProviderUIAPI in category Under Development? > (Other APIs in module api.search were marked as Stable.) I've marked SearchProviderUIAPI as Stable, too.
> Is API review needed before making the API stable? I'm starting a fast API review, just to be sure that the stabilization is OK.
> > Is it OK to keep API SearchProviderUIAPI in category Under Development? > > (Other APIs in module api.search were marked as Stable.) > I've marked SearchProviderUIAPI as Stable, too. That is simpler. When there are two independently stable APIs in one module, there is a problem with versioning. When only one of the APIs changes incompatibly, should the version change incompatibly or not? Jesse proposed a solution[1] based on proximity[2], but we don't have such system in place (except producing OSGi bundle and using what is in OSGi currently). [1] http://wiki.netbeans.org/NbmPackageStability [2] http://wiki.apidesign.org/wiki/Proximity
If there are no objections, I'll integrate tomorrow. Thank you.
Integrated as http://hg.netbeans.org/core-main/rev/20ed82f5d7d0
Integrated into 'main-golden', will be available in build *201303092300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/20ed82f5d7d0 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #160415: Stabilize Search API
Integrated into 'main-golden', will be available in build *201303112300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/0a92d7174d7a User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #160415: Moving links in package.html to second paragraph (Not to break relative paths in overview-summary.html)
I can see proper javadoc at http://bits.netbeans.org/dev/javadoc/ marking verified.