For instance, when exporting a file, we now have namespaces such as

• xmlns:jcrutils="xalan://it.openmindonline.urmetdomus.assembler.utils.Path" ?
• xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" ??
• xmlns:stringutils="xalan://org.apache.commons.lang.StringUtils" StringUtils????
  and other just-as-suspicious ones, such as xmlns:x="urn:schemas-microsoft-com:office:excel".

Findings:

Jackrabbit has a centralized namespaces registry. It stores/caches the registered namespaces under repositories/magnolia/repository/namespaces/ns_idx.properties and repositories/magnolia/repository/namespaces/ns_reg.properties

When you start with a clean repo, it only has very basic NSs (jackrabbit, jcr, mgnl). As soon as you bootstrap one of the "infected" files, however, the "suspicious" NSs from that file are registered. Subsequently, any node that you will export from this repository will result in an exported file with these namespaces. That's why I used the word "infected" - because as soon as one has bootstrapped such a weird file, your system is basically "infected".

This was probably introduced by accident in ONE file (namely one bootstrap file of the cache, which is the first to register these NSs when installing a fresh instance) and subsequently spread to all the others.

The oldest revision I can find that introduced (some of) these namespaces is r24820 for magnolia-module-cache/src/main/resources/mgnl-bootstrap/cache/config.modules.cache.config.configurations.default.xml (MAGNOLIA-2616)

How or why these were introduced at that point is still a mystery (maybe a buggy Jackrabbit was used when this file was exported, or the file was tempered upon using some misbehaving tool)

To avoid having to start from a clean repo, I think (to be double-checked) that simply removing the ns_idx.properties and ns_reg.properties files could work.