A tech discussion can take place where to agree on the strategy to follow. This will affect the work that will need to be done. See options section

Problem statement

When documenting the type aliases, we've realised we have

• missing aliases
• inconsistent naming, such as prefixed aliases (e.g. contentDepedencies:field)
• redundant aliases (classes which are just abstract classes, e.g. jcrNodeProvider)

Options

The aim was to simplify the configuration by easily remembering simply named aliases.
It makes it hard for the user to choose the correct one among huge number of aliases.

The DOCu point of view is that we should have aliases only for reusable definitions, typically generic JCR, JSON apps. Not for definitions scoped to custom apps - pages, tasks, notifications, definitions, addons...).

• Considering covering the module-specific definitions with aliases as well - this would require name-spacing them.
  • pro: leaner, more declarative yamls, more freedom with renaming and moving around classes
  • con: some of these aliases won't be used anywhere - will they be documented? This creates overhead.