1 is definitely the better approach.

as konrad mentioned as well, 1 could be combined with improved defaults in the 
downstream-tooling (e.g. aem analyser plugin). it should be possible to 
register the well-known namespaces used in AEM context there as default, that 
should cover most of the failures to be expected in existing projects.

from a sling perspective it's good to fail early in the build process if the 
mappings are missing, assuming the error message clearly indicates what to do 
to solve it.

stefan

> -----Original Message-----
> From: Robert Munteanu <[email protected]>
> Sent: Monday, May 8, 2023 6:07 PM
> To: [email protected]
> Subject: SLING-11865 - Conversion fails when initial content document does
> not include namespace declaration
> 
> Hi,
> 
> After cutting the cpconverter 1.3.2 release I noticed a change in
> behaviour with respect to ill-formed Sling initial content files. [1], [2]
> 
> Previously (in version 1.3.0), an initial file that used custom namespaces
> but did not declare them using bundle headers
> 
> e.g.
> 
> <node>
>     <primaryNodeType>nt:unstructured</primaryNodeType>
>         <node>
>             <name>my:subnode</name>
>             <primaryNodeType>nt:unstructured</primaryNodeType>
>         </node>
>     </node>
> </node>
> 
> would generate an ill-formed DocView xml (aka FileVault format).
> However, that DocView xml would then be successfully processed when
> installing the bundle.
> 
> With version 1.3.2 this kind of file is rejected since we have moved to
> using FileVault for generating the DocView xml.
> 
> The FileVault refactoring is good and allows us to drop custom code and
> old dependencies. At the same time, since I spotted this problem when
> updating AEM tooling [3], I am concerned that there are projects out there
> using the ill-formed initial content format that will be broken.
> 
> As Konrad suggested, I'd like to hear what others think and maybe gather
> some new options to proceed. Currently we have:
> 
> 1. Keep the new behaviour
> 2. Revert to the old behaviour
> 
> I am not sure if there is a middle ground, Konrad says that the FileVault
> serialisation code cannot work with missing/invalid namespace mappings.
> 
> Thoughts?
> 
> Thanks,
> Robert
> 
> 
> [1]: https://issues.apache.org/jira/browse/SLING-11865
> [2]:
> https://github.com/apache/sling-org-apache-sling-feature-
> cpconverter/pull/168
> [3]: https://github.com/adobe/aemanalyser-maven-plugin/pull/205

Reply via email to