Re: Tasklist SPIs

Petr Kuzel wrote:

>Hello,
>
>I'd like to do incompatible API change. 
>
>DocumentSuggestionProvider has several abstract 
>methods taking DataObject and Document arguments.
>Looking around code most providers need String
>of FileObject. If no objections I'll replace
>these by one wrapper object: 
>
>  /**
>   * @deprecated Experimental SPI
>   */
>  public final class SuggestionContext {
>     // package private constructor accessible by framework
>
>     /** Returns in-memory representation */
>     public CharSequence getCharSequence();
>
>     /** Return fs level representation */
>     public FileObject getFileObject();
>  }
>
>
>Moreover I need to figure out actual API stability level.
>I wish friend stability level answer :-). Then I plan to
>mark all APIs as @deprecated with experimental note.
>  
>

Looks good to me.  I'd noticed the same problem, and there are probably 
some @todo markers left in the source code where I said that it's bad 
that each and every SuggestionProvider goes and extracts the String from 
the document; it ought to be done once, and the result passed to each of 
the SuggestionProviders, which is precisely what the above would allow.

Regarding API stability: I don't think anybody other than Julian Sinai 
has actually built stuff on top of these APIs, so just check with him 
(he used to be on this alias, he might still be).

>Another issue, I'm confused about API packaging. It's
>in ....tasklist.api package but it should be in
>...taslist.spi package (framework calls to it).
>  
>

For what it's worth - that's where they -used- to be (try cvs log in the 
spi package - you'll see that DocumentSuggestionProvider.java was there 
until revision 1.11).  SuggestionProvider was erroneously there, as 
discussed here: 
http://www.netbeans.org/servlets/ReadMsg?msgId=397508&listName=nbdev .

I later started building in special support for 
DocumentSuggestionProvider in the framework; for example, the 
SuggestionManager looks for DocumentSuggestionProviders, and calls the 
special methods on it.  Thus, it's no longer an SPI (by the definition 
given by Jesse in the above thread, if I read it right) but an actual 
API;  in particular, if you implement your own SuggestionProvider 
without subclassing DocumentSuggestionProvider, it won't behave right 
since I'm doing instanceof checks etc.

But I can certainly see that this point is not made clear in the 
javadoc's, it probably should be (or better yet, if you can think of a 
way to clean it up such that it -can- be a pure SPI.)

-- Tor