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
Complicates issue #103187 because code in the wrong place is interpreting folder
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
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
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
Ah, I missed that.