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.
Ergonomics, but not only ergonomics would benefit from ability to register additional layer XML files into the content of system directory. The system would then include these layers into BinaryFS cache, offering effective access to the content on subsequent start.
Interface like public interface org.openide.modules.LayerProvider { void findLayers(Collection<? super URL> toAdd); } could work. I am not sure how to verify, validate and invalidate the caches.
Created attachment 108605 [details] Introducing LayersProvider interface Ergnomics or other systems that somehow extract layers from a list of modules will implement the interface and return list of layer URLs. Reviewers, please review. Hřebejku, please test.
[PH01] Thinking about it. Now in order to generate content of the FS. We create a set of XML documents (usually in form of DOM) then print them (into memory) and put them into the FS API. The implementation likely parses them again into DOM and then creates the files and folders on the FS. IMO it would be more effective if we would have an API for building content of the FS directly. I.e. creating the files folders. Not only it would be faster but it could also permit for e.g. checking if given file already exists.
Is there a concrete use case for this? It is hard to evaluate without more details. In particular, what is wrong with the existing SPI (bug #26338) which allows you to register a FileSystem into global Lookup? (Which already addresses PH01 as I understand it.) The only thing missing currently is cache integration, but I do not see any reason why that could not be added, given some reflective pseudoattribute syntax such as in the fix of bug #120724. (*) There are also known use cases for dynamic changes to the set of injected layers, which of course should not be cached; ActiveConfigAction in the project system uses this, and http://blogs.oracle.com/geertjan/entry/jdesktoppane_on_the_netbeans_platform describes how to use this to switch the main menu bar. (*) #120724 looks to implement raw:* even on getAttribute, though that is apparently undocumented. WritableXMLFileSystem in apisupport uses a more general literal:* syntax which bypasses java.util.reflect, useful when the classes in question cannot be accessed at development time.
Ergonomics is the primary usecase. Rather than having its own MultiFS and BinaryFS, with LayersProvider interface ergonomics could merge its data into the single shared BinaryFS cache. In the light of bug 199740 (which shows that each delegate in MultiFS comes with a cost), this would make the system more effective. Hřebejk has secondary usecase. He is converting parts of JSR 198 extension.xml to FileObjects, so they can be stored in a cache and don't have to be parsed on every start. For Hřebejk PH01 makes sense, as he does not have the layer.xml yet. Ergonomics don't need PH01 at all. Actually when thinking about the builder API, I was more attracted by: http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/annotations/LayerBuilder.html not only it would give shared API for compiletime & runtime, but it would be easy to verify that the runtime behaves correctly.
Created attachment 115423 [details] LayersProvider is ready for future evolution Hřebejk's usecase is no longer a blocker as Hřebejk is using BinaryFS directly, see bug 206072). Still, it makes sense to change the LayersProvider class to be more flexible for the future - e.g. allow builders of content rather than URLs in the future. Here is the new version. That has a method that takes Collection rather than one to return it. In future we can introduce new method that will take Collection and a builder or only a builder interface and as a fallback delegate to the already existing method. I'd like to integrate on Friday.
I've created a branch http://hg.netbeans.org/ergonomics/rev/53d2dfd6e7a1
Do not have time to review in full detail before then but quickly: [JG01] Suggest "LayerProvider" rather than "LayersProvider" (compound nouns in English usually cannot use internal plural forms). [JG02] Maybe include some kind of a key (assignable to Serializable? or String?) permitting a provider to help control when the cache should be rebuilt, in case something more than module list matters. [JG03] Passing in a Collection<? super T> is a little risky; what if the provider calls clear() etc. despite the Javadoc? Is addAll OK? Safer to pass in a callback interface with an add(T) method. [JG04] Existing documentation mentioning inserting a FS into default lookup should suggest using this instead. [JG05] Document behavior w.r.t. propagation of masks.
changeset: 212189:2eb1ef99ae1b branch: layers-provider-198508 parent: 212062:53d2dfd6e7a1 user: Jaroslav Tulach <jtulach@netbeans.org> date: Thu Feb 02 10:32:58 2012 +0100 summary: JG01: using singular name changeset: 212190:83cd1016db1c branch: layers-provider-198508 user: Jaroslav Tulach <jtulach@netbeans.org> date: Thu Feb 02 10:41:11 2012 +0100 summary: JG03: To shield against context.clear() and similar call, let's use a dedicated array for each call to registerLayers changeset: 212191:83bcf0e02437 branch: layers-provider-198508 user: Jaroslav Tulach <jtulach@netbeans.org> date: Thu Feb 02 11:07:50 2012 +0100 summary: JG04: Better and crosslinked javadoc changeset: 212192:c6f85f7f5467 branch: layers-provider-198508 tag: tip user: Jaroslav Tulach <jtulach@netbeans.org> date: Thu Feb 02 11:10:21 2012 +0100 summary: JG05: Documented where the layers go. The ergonomics usecase needs them below standard module layers. Re. JG02 - none of existing usecases needs that, will add it when needed. Still on track to integrate tomorrow.
Merged as ergonomics#69a8a720a65d