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.
The SideBarFactoriesProvider class is final and also used from the Lookup by the CustomizableSideBar.java. This means that no other FactoriesProvider may be implemented. A better approach would be to have an interface named SideBarFactoriesProvider which is accessed by CustomizableSideBar and an actual class SideBarFactoriesProviderImpl that does the current job. This way alternative implementations are not blocked. CustomizableSideBar is also directly used by NbEditorUI for example so that can't be replaced either and thus we can't get rid of SideBarFactoriesProvider (indirectly, be replacing CustomizableSideBar with our own implementation). Having SideBarFactoriesProvider as a final class is problematic for standalone usage of the Editor API as the current implementation likes to read the layer (it needs FileObjects). It would be nice to have at least another implementation that uses the Lookup or some other mechanism. One can have a filesystem in standalone usage but it's just overkill to use just to please SideBarFactoriesProvider.
SideBarFactoriesProvider is intentionally final. If you want to add your own side bar, just register you implementation of SideBarFactory in the 'SideBar' subfolder of your mime type under the Editors. What is wrong on using layers in a standalone application. It should work just fine. If not, please file defects for specific problems. Thanks.
It's wrong to have a dependency on the layer as a configuration system and not allow any other way. I don't want to add my own SideBarFactory, I like the default ones. I just don't want to use the filesystem module just to make SideBarFactoriesProvider happy. It just adds another dependency for no reason and makes the whole thing inflexible: for example if I want to dynamically add/remove a factory I have to add/delete the .instance from the layer. Maybe SideBarFactoriesProvider needs to be kept final (as the provider that loads stuff from layers), but a SPI would be needed to be able to add my own SideBarFactoriesProvider that CustomizableSideBar will lookup in order to build the sidebar.
Using XML layers for registering stuff is a standard concept in Netbeans. The editor modules are no different from others in using this concept and I don't see why they should be any different. If you thing that the concept is wrong or there should be alternatives please open that discussion on dev@openide. If this is an issue it definitely won't affect the editor only.