Page History

...

Where 'S' is an optional folder suffix. Note that services registered in subfolders do not mix, and they do not mix with 'generic' services in the base MIMEtype folder (no subfolder suffix) either.  The most generic registrations reside in Editor/{S }. MIME service registrations are usually processed in the order enumerated by the Lookup by editor and other servicessubsystems. So if one defines a position attribute for a registration .instance file, that file is ordered accordingly in the enumeration.

...

Generic services (in Editors/) typically do not have any position/ordering information.  Most languages are just indifferent to the order. Maybe it's not important for the function, or the  just do not define any order. I suppose that that the natural (declaration) order (textual order of appearance in the layer XML) is what the language implementation wantssatisfies the needs, especially if the registrations are written in the XML layer file. The This language's assumption may break once an extension is developed, with specific needs for ordering. The important thing to remember is that some or mime-specific folders define order, but some do not.

...

Look at an experimental branch and its diff against master: https://github.com/apache/netbeans/compare/master...sdedic:origin/bugfix/commitvalidation-fixes3?expand=1

Summary of problem

• there's NO WAY how to register a service in Editors/ (unspecified mimetype), that would pass current commit-validation
• the unspecified mimetype ("") was specifically designed to define universal services, for all editors (without that, this is what the entire MIME inheritance is about)
• once some obscure module eregisters a service in "" MIME type, he is likely to force all distribution modules to use positions in their registrations from that time onwards. Remember: if ANY mimetype uses positions in a specific MIME subfolder, all must use them (in that subfolder).

...