Don't run the aem-content-classification on package type content

[royteeuwen]

I have put the configuration for the aem-content-classification in the parent project, but now my ui.content module fails for reasons like the following:

[ERROR] ValidationViolation: Element with name "content (Namespace URI: http://www.jcp.org/jcr/1.0)" references resource 'dam/cfm/models/console/components/data/entity/default' which is marked as 'granite:InternalArea'. It therefore violates the content classification! @ jcr_root/conf/dam/my-site/settings/dam/cfm/models/my-model/.content.xml, line 18, column 30, validator: netcentric-aem-classification, JCR node path: /conf/dam/my-site/settings/dam/cfm/models/my-model/jcr:content

Unless I'm mistaken, this actually isn't an issue and maybe the content classification should be turned off for packages of type content?

[kwin]

Why do you think this shouldn't apply to content references? https://experienceleague.adobe.com/en/docs/experience-manager-65/content/implementing/deploying/upgrading/sustainable-upgrades#content-classifications clearly says:

Internal (granite:InternalArea) - Defines a node as internal. Nodes classified as internal ideally should not be overlaid, inherited, or used directly. These nodes are meant only for internal functionality of AEM

Usage for me covers includes usage in custom content.
Otherwise I wouldn't understand what granite:finalArea is for

Final (granite:FinalArea) - Defines a node as final. Nodes classified as final ideally should not be overlaid or inherited. Final nodes can be used directly by way of sling:resourceType. Subnodes under final node are considered internal by default.

Whether you reference from via sling:resourceType from either /apps or /content does not matter. You reference it (which might break in the future if Adobe is removing/renaming that resource type).

[royteeuwen]

@kwin well that would mean you aren't allowed to have content fragment models in your codebase?

1. Start up a fresh AEM 6.6.1
2. Go to http://localhost:4502/conf/core-components-examples/settings/dam/cfm/models/office.-1.json
3. See that the jcr:content node has sling:resourceType = dam/cfm/models/console/components/data/entity/default => This is granite:InternalArea

This is only one of the examples, other ones I found:

• You can't define maintenance tasks in code
• You can't define workflows in code
• You can't define AEM forms themes in code
• ...

[kwin]

It rather means Adobe messed up the content classification in this case :-). If content references are allowed I wouldn't understand why at the same time you shouldn't allow usage via sling:resourceType from /apps (Both work/break in the same way). Compare with https://github.com/Netcentric/aem-classification/blob/master/aem-classification-maps/aem-classification-map-repo-annotations/README.md#known-incorrect-classifications.

[royteeuwen]

OK, already made one adobe support ticket today for AEM Forms Core components that use resource types that are wrongly content classified, will see based on the outcome of that one if I'm still willing to make other ones or just ignore them locally 😅!

[kwin]

Feel free to reach out to Adobe support, to get clarification how to interpret granite:InternalArea correctly. For me this should be used on things which are not supposed to be referenced from outside Adobe code/content. Unfortunately they often use that instead of granite:finalArea even for things which need to be referenced in custom content as well.