How to remove obsolete /etc/map entries on Publish?

[MeasurableBusinessResults]

I have a package that install the etc map entries on my Publishers.
I currently have some mapping configs there that are obsolete, but must be removed because they break the new correct mapping.

all my mappings are located underneath /etc/map.example
The rule in the filter.xml is

<filter root="/etc/map.example" mode="replace"/>

so I would expect the whole tree underneath to be wiped and replaced (according to https://jackrabbit.apache.org/filevault/filter.html ), but this is clearly not what happens - I checked in the AEM cloud Publish Repository Browser and the old nodes are still there.
Unfortunately the Repo Browser has no option to delete stuff.

The nodes I need to delete are as follows:

/etc/map.example/integration.publish/https/integration.example.com/redirect_old
/etc/map.example/integration.publish/https/integration.example.fr
/etc/map.example/integration.publish/https/integration.example.de
/etc/map.example/integration.publish/https/integration.example.it

where "integration" is the name of my environment and ideally I want to use a wildcard to make this match for all environment mapping configs that also have to be cleaned.

In addition, how can I ensure that underneath integration.example.com, ONLY the listed "redirect_old" node is removed, but not other nodes that also exist there and/or are added with the same package?

The question is:
How would my filter.xml entry look like to actively remove nodes from AEM?
(nodes do no longer exist in the package, but still exist in the AEM repository)

[Karishma_begumSh]

HI @MeasurableBusinessResults 

Explicit Delete using mode="replace" + empty node in package

If you can modify your package content:

1. In your project, add empty folders for the paths you want to remove,
   and add a .content.xml with jcr:primaryType="nt:unstructured" but no children.
2. In filter.xml, use mode="replace" for that specific path.

<filter root="/etc/map.example/integration.publish/https/integration.example.com/redirect_old" mode="replace"/>
<filter root="/etc/map.example/integration.publish/https/integration.example.fr" mode="replace"/>
<filter root="/etc/map.example/integration.publish/https/integration.example.de" mode="replace"/>
<filter root="/etc/map.example/integration.publish/https/integration.example.it" mode="replace"/>

When deployed, these nodes are replaced with the minimal structure from your package.

or try

Use mode="merge" on parent + explicit <exclude> rules

If you need to preserve other mappings, but delete specific old nodes:

You can use mode="merge" for /etc/map.example/integration.publish/https/integration.example.com and add

<filter root="/etc/map.example/integration.publish/https/integration.example.com" mode="merge">
    <exclude pattern="/etc/map.example/integration.publish/https/integration.example.com/redirect_old"/>
</filter>
<filter root="/etc/map.example/integration.publish/https/integration.example.fr" mode="replace"/>
<filter root="/etc/map.example/integration.publish/https/integration.example.de" mode="replace"/>
<filter root="/etc/map.example/integration.publish/https/integration.example.it" mode="replace"/>

Regards,

Karishma.

[MeasurableBusinessResults]

Thanks Karishma, but trial-and-error is not something I was looking for. 😉

Your second suggestion contradicts the Jackrabbit documentation in two ways: 

1. "merge" mode by definition does never modify existing content
2. an exclude pattern makes the package manager skip this node upon installation (regardless of whats in the package or in the target repo)

so I do not see how the combination of these two approaches that would fail already by each of themselves, should suddenly work in combination?

As for force-overwriting the node with a different jcr:primaryType that is no slingMapping (and thus ignored by the mapping engine altogether): yes, that could probably work, but it leaves all kinds of dead orphaned nodes in my environments that have no functional effect, so I would consider it a "hack" that should only be used as a last resort.

I am assuming there must be a proper and clean way to remove unnecessary nodes from a Publisher. 

[MeasurableBusinessResults]

I discovered the root cause of the issue. The jackrabbit documentation is actually correct: it only requires the "replace" mode on the parent filter.xml entry, and then the actual child nodes need to be absent in the package - this will remove them.

But there were two issues preventing this:

1.

An obsolete redundant entry in the filter.xml (some historic legacy or default), before/above the /etc/map.example entry:

<filter root="/etc" mode="merge"/>

this prevented the replace, because the effective mode was "merge" instead, which does not touch existing nodes in the repo.

2.
Some of the intermediate folder nodes had a .content.xml which did not explicitly list the child folders, e.g. at the 
/etc/map.example
and

/etc/map.example/integration.publish

levels.

The explicit listing of child folder nodes seems to be necessary to cause the "replace" mode to actually remove all children that are not present in the package.

Once this is done, the filters work exactly as documented in Jackrabbit

[muskaanchandwani]

Hello @MeasurableBusinessResults 
Another way you can try to delete a node from the Publisher is by sending a "Delete" action Request from the Author Distribution UI. You may refer to the Article [1] for more information in this regard.

[1] https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-22828