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  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.

...

During fixing commit-validation, in PR-2359 (https://github.com/apache/netbeans/pull/2359), I tried to introduce automatically generated positions, if the annotated element just does not care: this fixes the usual MIME use case: if the provider does not care, just define _some_ order, at the end (to remind: a special value of 0 means that the position is irrelevant, but should be put sorted first).

It turned out that all those declaration order registrations (Latte, HTML, ...) broke and had to define an explicit order now, so they do not produce a warning in presence of auto-generated position attributes. Which is not entirely bad: Without an order explicitly set, with sufficient 'gaps', the MIME type is not extensible: If a XML (text/x-xml) defines two providers with no order, then it is impossible for JavaFX FMXL (text/x-fxml+xml) to insert a provider in between those two.  But for most languages,which (typically) do not provide services or boilerplate for others. this is just a complication. 

Another breakage was introduced by "some module" (java hints) that declared in UpToDateStatusProvider using annotation, which auto-declared the position. As a result, about 10-15 registrations of other UpToDateStatusProviders, in base Editors/ and all other MIME types neede to be changed: at first, the position in a specific MIME type caused generic Providers with positions undefined to fail commit-validation  test. In the subsequent round (when these were fitted with appropriate position values), the other MIME types that declared UpToDateStatusProvider started failing.

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).

...