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.
RIF makes heavy use of Datasystems semantics: 1. Folder ordering. 2. Detailed format of .instance files. Yet these things are defined in openide/loaders. (FolderOrder and InstanceDataObject.)
Complicates issue #103187 because code in the wrong place is interpreting folder ordering attributes.
Well, it cannot be in loaders, it would be useless. The goal was to allow applications written on top of NetBeans Runtime Container (e.g. without openide/loaders) to be able to use Lookups.forPath to read something from folders on system file system. This is satisfied. Re.: "use of Datasystems semantics" - sure. It behaves as simplified FolderLookup. Of course that it has to have similar semantics. I am not sure what exactly you do in issue #103187, maybe we could find a way to write the code in different way, share it between multiple usages, etc. However the general goal - e.g. ability to interpret SFS as instances without openide/loaders - is something I want to keep.
I guess I don't follow what the purpose of not using openide/loaders is. If you want the semantics of InstanceDataObject, you should simply use the API module which provides that semantics. Why not? For issue #103187 I expect to need a common API in openide/fs which could be used in RIF.
Re. "purpose": once upon a time there used to be a discussion. Was it right to use openide/loaders for settings management or not? Was not it too heavyweight to empower all the loader stuff to just read a menu definition? Well, yes it was. The issue 98426 creates an alternative. #1 it is possible to read declarative registration with Lookups.forPath, #2 one can use .instance syntax on SFS without relying on loaders at all. Of course, the advanced tricks of openide/loaders - e.g. .settings files, or InstanceCookie in any kind of object, etc. are not supported. But that does not matter from the point of view of an extension point provider: "If you want to register something for me, put .instance files into X/Y/Z folder on system file system. If you want to register something more complex, then depend on core/settings, follow their contract and use .settings files, convertors, or your own loaders with InstanceCookie. I do not care, I use single common API that can read X/Y/Z for me."
Re. "Single API in RIF" - #1 it is not very good to create an API just for one client. #2 maybe you do not need this API to be public, core/startup and openide/fs are loaded by the same classloader anyway or can have impl dependency. #3 recently you moved layer parsing to openide/fs, maybe the RIF could be implemented in openide/fs as well, then there would be no need for an API
I don't understand how using Lookups.forPath will allow you to read more complex settings with *.settings etc. FolderLookup would read them, but AFAICT L.fP will not. RIF could equally well be in openide/fs; no strong opinion. But the API for folder ordering I mentioned is needed from other places, not just RIF. See wiki for the list.
When core/settings is installed, L.fP reads the SFS content using FolderLookup.
Ah, I missed that.