Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DO NOT test for mix positions / no positions in Editors/* area under FileUtil.getConfigRoot(). This is the easiest, but we loose the assurance of some order of the registered services .(which is IMHO too strict anyway, given the scenarios above)

Define positions (almost) everywhere

...

The MIME annotation processor would then by default generate nothing (again). LSP or other generic registrations cam use either 0.0, or -whatever.0, depending on whether order is or is not important. Furthermore,

If the FileSystem API changes as 

Code Block
languagejava
FileUtil.getOrder(Collection<FileObject> items, @Nullable Number defaultOrder, boolean printWarnings)

MIME lookup implementation can imply its default (in its registration area) without bloating the layers and without printing unnecessary warnings.That the MIME lookup is composed as MultiFileSystem from the layers (individual MIME types), starting with the most specific, the most generic last. Beacause of the way how MultiFileSystem is implemented, child files are enumerated in the order of the delegates: that is, they will be enumerated starting from the most specific to the least specific ones. In this scenario, Given how (implementation-wise) the MIME MultiFileSystem is composed:

  • position float="0.0" will favour the more specific declarations over the less specific ones, provided none of them has position defined;
  • declarations with positions defined will sort according to those positions, AFTER all intvalue="0" (compatibility) and BEFORE floatvalue="0.0" (new feature);

...

  • most modules can continue to write .instance files without any positions.
  • @MimeRegistration need not to specify or generate positions
  • wherever positions are defined, they are used to order the positioned items.
  • the hack for ProjectType service registry will be eliminated

Consistency check

The current consistency check is too strict - as outlined above, it basically prevents introduction of generic services to MIME lookup - only at expense of ordering the service folders in all MIME types in the the whole NetBeans distribution. But it is still good to ensure that the order is well-defined on individual levels of MIME registry, e.g. that a particular language either defines order for all service registrations, or for none of them. With the proposed changes above, generic services will be typically registered in a way that does not define order. So the test will primarily ensure that if the language defines order on services, the order is well-defined.