[
https://issues.apache.org/jira/browse/JCRVLT-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-845:
-----------------------------------
Summary: filevault-package:validate-package does not evaluate filter.xml in
the same way that the importer does (only consider first matching root) (was:
filevault-package:validate-package mismatch in behavior with actual
installation)
> filevault-package:validate-package does not evaluate filter.xml in the same
> way that the importer does (only consider first matching root)
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-845
> URL: https://issues.apache.org/jira/browse/JCRVLT-845
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
> Affects Versions: package-maven-plugin-1.4.0
> Reporter: Santiago García Pimentel
> Priority: Major
>
> I recently stumbled upon the issue that filevault finds the first filter that
> matches the root instead of finding the closest one
> (https://issues.apache.org/jira/browse/JCRVLT-96)
> still. when this happens, the validator not mark as not covered nodes on
> those circumstances.
> e.g. for these filter entries:
> {quote}<filter root="/conf/app" mode="merge_properties">
> <exclude pattern="/conf/app/settings/conf1(/.*)?"/>
> </filter>
> <filter root="/conf/app/settings/conf1" mode="replace"/>
> {quote}
> Due to JCRVLT-96 any content below conf1 will actually be excluded from
> installation (since it picked the first one, which excludes it) but the
> validator will not mark it as not covered by a filter this since a second
> filter (which actually never applies) exists.
> if the behavior described in JCRVLT-96 does not change (which after 10 years
> it probably wont) the validator should at least behave consistently.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
