Let system settings for JS extended portlets be categorized

• Type: Story
• Status: Closed
• Priority: Minor
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: Master
• Component/s: Portal Configuration, Portal Configuration > System Settings
• Labels: None
• Epic Link: fi-frontend-application-development-improvements
• Sprint: S02E08 - The Usual Suspects, S02E09 - The Lion King, S02E10 - Fight Club
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/68533

Right now all JS extended portlet configurations end up in the "Third party" category because we have no way to create an ExtendedObjectClassDefinition annotation. We could, but we would need to generate bytecode on the fly during runtime and we don't want to do that in this moment because release is near.

—

The specification for this is the following:

 

• What's being done now:

Whenever an OSGi bundle is found with existing metatype information (placed in `OSGI-INF/metatype.xml` as per the spec) the configuration admin portlet looks for an `ExtendedObjectClassDefinition` annotation in the Java interface describing the metatype structure.

If found, it uses the `category` field of the annotation to obtain the category key for placing the configuration dialog.

 

• What we are adding:

If the interface describing the configuration structure is not found, the portlet falls back to the `features/metatype.json` file which is usually placed inside the JAR by the `liferay-npm-bundler`.

That file contains one field named `category` and its value is used to decide the category key for placing the configuration dialog.