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.
there's a plan for a new tasklist / problems framework for nb 6.0 to show java error and warnings. nbfeature: http://netbeans.czech.sun.com/wiki/view/Nbplan/NbFeature1288 ui specification: http://core.netbeans.org/proposals/tasklist_ui_spec.htm (already reviewed) implementation prototype: contrib/tasklist the api change is addition of a new SPI module (proposed location is core/tasklist or core/problems) that will provide java interface for other modules willing to integrate with the new tasklist. see javadoc for more details.
Created attachment 39404 [details] arch
Created attachment 39405 [details] javadoc
Y01 usecases shall have links to classes - e.g. no TaskProvider, but <a href="@TOP@....TaskProvider.html">TaskProvider</a> Y02 "registered in XML layer in folder" - should be defined as exported layer API using <api ....>description</api> Y03 I know I've heard that before, but what is the purpose of ResourceContext if it returns FileObject? Just use FileObject! If you want to hide it, then remove the getFileObject method. Y04 Isolate TaskProviders - e.g. do not make them call into a singleton class TaskManager to refresh something - use listeners Y05 If Y04 is implemented is there any reason for keeping TaskManager? Who is supposed to call it except the UI module of tasklist? Y06 How big is test coverage of the API?
JL01: If the current Java infrastructure (and possibly infrastructures for other languages) needs to process many files, it processes them much faster "all at once" than "one by one". The proposed API makes batch processing inconvenient at least. I think we should discuss if it would be possible to make the API more batch processing friendly. JL02: It would be nice if there existed something like: TaskManager.needsRefresh(String taskType, FileObject root) (or analogous on the listener if Y04 is implemented) meaning that all files under the root need refresh. This method should be cheap if no file under root is in the currently selected scope. If this method existed, the TaskProvider could simply call needsRefresh as necessary without checking the current TaskScanningScope. Also, TaskManager.needsRefresh(String[] taskTypes, ResourceContext[] ctx) should be cheap if the given resource(s) are not in the currently selected scope. JL03: What is the reason for TaskManager.needsRefresh(TaskScanningScope)? JL04: TaskGroup is Comparable - maybe implementation leaks into the API? JL05: TaskManager.needsRefresh(String[], ResourceContext[]) could use "..." to specify ResourceContexts.
PN01: There seems to be some conceptual overlap with hints framework (editor/hints). Shouldn't we somehow join them? PN02: TaskProvider.scan() is filling passed List. Does that mean it can clear other providers' Tasks from the List? (i.e. is the List shared?) Or is this just to overcome single return value problem? PN02a: Why ScanResultValue? If scan just returned a Collection, it can be non-null (even empty) meaning also SCAN_OK or null, meaning KEEP_PREVIOUS_DATA if there were any, or NOT_SUPPORTED if not, the impact on the infrastructure should be the same anyway. Transition between SCAN_OK/KEEP_PREVIOUS_DATA and NOT_SUPPORTED is not a usecase in my opinion. PN03: ScanResultValue.NOT_SUPPORTED suggest some kind of content type filtering. Shouldn't content type affinity be expressed in advance (by TaskProvider) or declaratively (registration hierarchy, maybe mime lookup)? PN04: What kind of events will I receive if I register on TaskManager? What are they useful for? PN05: TaskProvider.openCustomizer is quite unusual pattern. I'd rather go for Component getCustomizer() or some navigation into options dialog. PN06: What are the semantics of TaskProvider.getType()? Can I choose the string freely or is there any guideline? What if I (unintentionally) clash with other provider?
PN07: notifyPrepare/notifyFinish is obviously meant to support batch processing, yet notifyPrepare has not context (prepare for what). But this can be covered in response to JL01, I guess. PN08: In wider scopes, I can imagine providing project-wide tasks that are not related to individual file (e.g. fix dependencies, user defined tasks). Is this out of scope of this proposal? PN09: TaskGroups are very loosely coupled with Tasks. They are identified by reference on one side and by String on the other side. Where does the provider get the String to pass to the Task.create factory?
Y11 Export one java api using <api/> so it is listed in the main javadoc page, change stability so it is not friend, private... Y12 Create one API change so you are listed in what is new. Y13 Missing javadoc. In SimpleTaskScanner.Callback for example. Y14 TaskScanningScope shall probably implement Lookup.Provider interface. Y15 Use links to actual classes in usecases
Y16 Create package.html so the package has some description
Is this issue still active?
nope, the review is finished already: http://wiki.netbeans.org/wiki/view/TaskListAPIReview