Since version 1.1.0 the Jackrabbit FileVault Package Maven Plugin validates the package contents against a set of validators that check the consistency and validness of your package content and filter definition.
In most cases the validation errors reported are correct, and you indeed have to some problems in your content package that need to be fixed.
An important configuration property of the Jackrabbit FileVault Package Maven Plugin is the packageType. Previous versions of the plugin already required this property, but did only few validations based on it. The documentation of this property lists these types:
application: An application package consists purely of application content. It serializes entire subtrees with no inclusion or exclusion filters. It does not contain any subpackages nor OSGi configuration or bundles.
Contains only (application) content below /apps or /libs.
content: A content package consists only of content and user defined configuration. It usually serializes entire subtrees but can contain inclusion or exclusion filters. it does not contain any subpackages nor OSGi configuration or bundles.
Contains only content below /content or /conf.
container: A container package only contains sub packages and OSGi configuration and bundles. The container package is only used as container for deployment.
Contains no content at all, but only OSGi configurations, bundles and/or sub packages
mixed: Catch all type for a combination of the above.
This is only for legacy use cases. You should avoid to use this package type.
So, before looking in detail on any of the validation errors or warnings, check that the package type is correct. The validations applied on the package depend on the package type.
If your package contains a mixture of the different package types you should split up or refactor your packages so that each one complies with one of the requirements of the first three package types. This is also important if you migrate to the AEM Cloud Service later on.
The validation messages which are printed by the plugin are usually quite self-explanatory. Try to fix them one-by-one until your build runs fine. Also check the warnings and try to resolve the issues as well.
If you are stuck with a rule violation where you have no valid fix and are sure that it will not create a problem when deploying on the AEM instances, you can disable single checks of the validators, or whole validators.
In this example, we reconfigure the jackrabbit-filter validator to tell him that it’s fine that the parent application folder is not contained in the package itself, and also not in a package declared as dependency:
If you do not want to define this extra package and are sure that the missing path will always exist when the package gets installed you can also reconfigure the filter to define the missing root as “valid root”:
Given root node name 'xxx:yyy' (implicitly given via filename) cannot be resolved
In case you get an error like this:
[ERROR] ValidationViolation: "jackrabbit-docviewparser: Invalid XML found: Given root node name 'cq:tags' (implicitly given via filename) cannot be resolved. The prefix used in the filename must be declared as XML namespace in the child docview XML as well!", filePath=jcr_root\content\_cq_tags\.content.xml, nodePath=/content/cq:tags
the folder name contains an escaped namespace (like _cq_tags), but the namespace declaration of “cq” is missing in the contained .content.xml. Solution: Add the missing namespace declaration, or re-export the package from AEM using the latest wcmio-content-package-maven-plugin.
Last resort: switch to old plugin version
If you have a content package with a very “legacy” structure and you currently do not have the time to really solve the reported violations, and currently do not have to care about requirements like AEM cloud service compatibility, you can switch to an older version of the plugin that does not contain all these new validations. Use this only as last resort.
<!-- This is a content package with a lot of legacy stuff that is not compatible with the package validations from the lastest plugin versions -->