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.
I am trying to make parts of the API support module usefull when running in the platform build. I have created a new module apisupport-platform that contains just the bean browser and adds a new workspace with it. I will attach both the new module and a small diff that it requires to run. All of this is done against release35 (for now). Please comment. I might be interested to put this into trunk one day.
Created attachment 12427 [details] tar.gz of the new (reduced) module
Created attachment 12428 [details] Diff for the apisupport module that is needed for the apisupport-platform
Please check the diff - it might be usefull even for the regular apisupport module. Thanks for any comments, suggestions etc.
The diff to CookieKids.java is unnecessary in the trunk, I think, due to the fact that issue #26617 already supports Lookup.Provider (I hope correctly) and CookieKids is deleted. Please try it in a dev build if you get a chance and file bugs if anything does not seem to be working correctly. There should be no need to restrict std-cookie-classes.xml; classes which are not found should be ignored. (Can adjust ErrorManager level as necessary). I am not sure what the purpose is of the window manager stuff in the apisupport/platform module, since I thought this is already provided by core/ui. And even if you had suppressed the Explorer and property sheet, it is easy to open them from the menus (and you can open Bean Browser on a given node from the Tools menu). Can you explain the intent? I think it would be fine to break up apisupport so that it does not depend on anything outside the platform, with the other stuff present in a separate module. This would be the most maintainable thing. Probably the deps would be apisupport/ant -> ant, etc. apisupport/lite -> apisupport/ant, java/* apisupport/platform -> nothing in particular apisupport -> apisupport/lite, apisupport/platform, etc. If you are interested in getting that into the trunk, you could attach a diff to the manifests, build scripts, etc. implementing it; if the patch works, I would rearrange sources so that they are contained in the proper directories. (This is painful to do in a CVS patch since there is no way of representing file renames.)
Hi, I have changed std-cookie-classes.xml because in release35 I was getting exceptions when the classes were not found. The window manager stuff is there to add a special workspace for all the stuff. Reason: if you have an application built on top of the platform I am sure you won't have Editing workspace - we even don't edit anything in our app ;-) So the editing workspace is branded away in some module. And for this API support you need something like the editing workspace - so I basically copied the needed things from the editing workspace of core/ui. As for the trunk: I will try to port everything I have to the trunk after I have all things done on release35. Should be soon - say January or so.
Re. exception from cookie class list - OK, better to just suppress the stack traces I guess. Re. special workspace - well that isn't going to work in the trunk anyway. :-) Suggest instead that a menu item be added to Window to display the Bean Browser (MainNode directly, not the Runtime tab!), perhaps in the "Documents" mode, with an internal SplitPane having a BeanTreeView on one side and a PropertySheetView on the other side. You can use WindowManager.findTopComponent(String) to singletonize the window even across sessions. Re. January-ish - fine. Not sure if that will make it into the 3.6 cycle or not, but for a beta module it doesn't matter too much anyway.
No current plans to work on this, I'm afraid.
Probably needs to be rethought in terms of new apisupport functionality.