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.
Layer is perfect for creating Extension Points and in combination with Lookups much more flexible and simple to use than anything OSGi has. The only thing that's missing is a way to mark up and describe the extension point. For starters it would be enough to have an attribute, e.g. <attr name="extensionpoint" stringvalue="some description"/> to fix this. I think we don't need that verbose XML stuff, Eclipse has for this, it's just more work, but an optional way to mark extension points would be great. It could then be used in various ways: * The UI for displaying "this layer in context" could then use this to display a tooltip text, and eventually badge the folder icon. Everyone would then be able to easily identify all extension points by browsing the layer and find out, what can be extended.
Maybe rather <folder name="notSelfExplaining" desc="Explain here.">. It is about visualization of layer in NetBeans project, so I am redirecting.
Has been considered in years past. Possibly WONTFIX as new APIs are encouraged to use annotations and annotation processors rather than manual layer registrations, in which case the annotation's Javadoc is the official documentation.
Java Docs have been the only source of information before, but they don't solve the problem. The usecase is that users ( like me ) want to explicitly find out which extension points are available. Right now with javadocs they need to stumble upon the info by chance or read somewhere else about it. For me that's the only thing where Eclipse extension points are better, you can easily get a list of the available extension points including documentation. I think a description attribute just would be enough to flag the extension point and the stringvalue could point to the JavaDoc with real documentation. Since the annotation based solution still creates layer files, I think it would still be possible to do it. Could the AnnotationProcessor maybe add some attribute? --Toni
A Javadoc overview has a list of all annotations. There is never going to be an exhaustive list of everything you could possibly register for any reason; you have to restrict the question to a particular API or use case.
I think it would be good to be able to browse "this layer in context" and find all the available extension points in order to get an idea of what is avilable. But even if you want to restrict the query to a specific API: In Eclipse it's easy to see a list of the available extension points via the ui (http://www.vogella.de/articles/EclipseExtensionPoint/article.html#simple_usingextension) when you set a dependency on an API. This simplifies the process of learning about the API and identifying the relevant parts a lot.
I have to agree with Toni (I hope I got maxnitribitt's identity right :)?) here, it was also one of my complains when I moved from Eclipse RCP to NetBeans, see http://wiki.netbeans.org/RichardMichalsky#section-RichardMichalsky-WeakPointsOfNBAPISupportComparedToEclipse. For someone not wholly familiar with platform capabilities a complete and centralized list of documented "extension points" is very useful and convenient starting point. However I see two problems here : 1) The solution with description in layer.xml allows layer entry *providers* (i.e. clients of the ext. point) to add a description, while we want the *consumer* of the entries (i.e. code that processes them) to describe it (but the consumer does not add any layer entry to which we could add the documentation). Annotations solve this, but you still have to browse dozens of individual API javadocs to get the overall picture. I guess even just a special javadoc page with all platform annotations described (like http://bits.netbeans.org/dev/javadoc/layers.html) would help a lot. Still there is no integration in IDE, such a page won't reflect user's custom platform and not all extensions can be currently declared with annotations (will they ever be?). 2) <this layer in context> UI is currently well behind annotations and won't probably ever catch up in its current form. One doesn't see annotation-generated entries until project is compiled, UI doesn't even support Add and GoTo for annotations and ext. point is not shown until it has at least one provider. So I guess we need a broader discussion and resolution regarding annotations, layers and support in IDE. At least to answer these: Will annotations fully replace XML-based entries and if so, when? Do we need special UI for annotations or will plain Java editor support do? Can we make current UI (<layer in context>) more useful in the meantime and is it worth the effort?
To #1 "there is no integration in IDE": try @ CTRL-SPACE "Will annotations fully replace XML-based entries and if so, when?" - they can, although the payback is lesser for entries not mapped to a single Java object; see my original wiki page. As to when, that is a matter for people managing schedules that I cannot comment on. I would at least expect all new APIs, and some of the more significant existing ones, to try to use annotations. -1 from me on special UI. A big reason to use annotations is to make use of the plain Java editor and not have any special UI.
@Richard: To #1: My idea was that consumers could provide an empty folder including the description, while providers would add content. (Yes, I'm Toni, I should probably change my username sometimes) @Jesse: Regarding "@ CTRL-SPACE": - It only works for extension points converted to annotations, so it's no complete list, and we don't know when and if it will ever be. - It only works for imported Modules, while this layer in context works for all Modules in an application. - It won't work for extension points where no Java code is involved for providing extensions, e.g. registering palette items via xml. I think it's a suboptimal solution. The layer UI in contrast would be able to easily address all of these points.
To your objections: - yes, but conversely a layer-oriented doc attr is useless for those registrations which _have_ been updated - you have to have some idea what you are looking to do if you are looking for detailed docs on how to do it; if there is some use case for seeing every possible kind of thing you could register with any SPI in the module universe, we could easily make a quick summary of annotations that you could browse to discover interesting stuff you had never heard of, which would be friendlier than going through a tree structure of "<this layer in context>" and trying to look for folders with docs on them (and would work better anyway since you may not be including all of those SPI modules in your suite yet); we have such a list already in http://bits.netbeans.org/dev/javadoc/layers.html which is easy enough to expand - still TBD whether we want to do it, but it's quite technically possible to use annotations even for these things (on packages)
No plans to go in this direction, as per previous discussion.