These two modules (API and storage) were always meant to work together. We have never imagined somebody would want to
implement their own storage. What is wrong on using both of them in a standalone editor app?

Although I have my own reservations to the checks done in constructors of o.n.e.settings classes I accepted the original
design done a few releases ago. The classes are supposed to be accessible only through MimeLookup and nobody, but the
editor infra should be able to supply their instances. The checks are there to enforce this. Please bring up this
discussion on dev@openide to get more attention and be prepared to present reasonable usecases.

I'm sorry to say this, but it's highly unlikely that anything will change on this API for nb6 this late in the release
cycle.

The first thing that I can think of is that I need to use the layer to configure the storage. I don't really need that
and it just complicates the API (when all I want is a MimeDataProvider with some MimeLookups that contain /my/
FontColorSettings).

As for the 2 modules being so tied together, I think this should be a good reason to join them into a single module.
After all, the whole ideea of the module system is to be able to declare services and thus remove/add service providers.

Well, I think I agree with you. I personally don't see any problem with allowing alternative storage modules. The whole
picture however is a bit more complicated. Since the Editor Settings API provides read-only access to the settings the
storage module is responsible for providing an API that allows settings manipulation. This API is now for-friends-only
and is used from the editor/options module that implements panels for Tools-Options. This effectively means that when
implementing another setting storage you will also have to provide your own Tools-Options panels.

I'm not saying this is ideal and we may need to revise this design one day, but that's what it is now and it works
reasonably well for Netbeans IDE. If you could provide us with some good (real world) usecases that would definitely be
useful for the future work in this area.

Well, in a standalone usage, I don't need the layers and I have my own way of storing the user settings (in a file , in
some Preference, on the server via some EJB).

So, first, using layers to configure everything and /not allowing/ any other way means basically that my API will look like:

void hideSomething(){
 getFSRoot().getFileObject("some.instance").delete();
}

while all I wanted all along was to have some Lookup / class where I can do a .hideIt() which probably does a
InstanceContent c.delete(oldReference)).

It just seems strange to play with the filesystem (even if it's an in-memory fs) just to get some API-like effects.

Regarding the storage and options, of course, if by implementing some SPI I need to provide many things (to make the
options happy) so be it. But the question is: why would I need the options implementation ? I'm not using
openide-windows so I'll probably just provide my own GUI for the settings.

I haven't look there yet, but I remember the option panels were just some JPanels so maybe they /are/ useable as a
standalone. But there is no reason to make this the only use-case possible. Maybe I just want another GUI or a limited
GUI with fewer options, etc.

Resolving all issues with milestone "future" as LATER. If you feel strongly that
it should be implemented please reopen and set the target milestone to "next".

NetBeans.org Migration: changing resolution from LATER to WONTFIX