[
https://issues.apache.org/jira/browse/SLING-12469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895576#comment-17895576
]
Robert Munteanu commented on SLING-12469:
-----------------------------------------
Right, we already make the distinction between FS and repository paths, see
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/a0914fb9050a9c3aecd5e69f0adb648b91796ce8/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java#L110-L113
.
What still puzzles me is the format of the index definitions - I stumbled upon
this "in the wild" but I don't think this is generated by FileVault, but rather
crafted by the user. My test was the following:
- start the Sling Starter
- create a filter.xml that includes two index definitionss
{code:xml}
<workspaceFilter vesion="1.0">
<filter root="/oak:index/jcrLanguage"/>
<filter root="/oak:index/counter"/>
</workspaceFilter>
{code}
and ran {{vlt --credentials admin:admin co
http://localhost:8080/server/default/jcr:root/}}.
I ended up with a generic aggregate for oak:index (
https://jackrabbit.apache.org/filevault/vaultfs.html#generic-aggregates )
{noformat}
$ tree -a jcr_root/
jcr_root/
├── .content.xml
├── _oak_index
│ ├── .content.xml
│ └── .vlt
└── .vlt
{noformat}
and not with individual full aggregates for each index definition. My current
thinking is the files were hand-crafted and accepted by FileVault for import,
but not representative of the canonical format used when exported.
> Index definitions are not extracted when individual definitions are defined
> in the filter.xml as roots
> ------------------------------------------------------------------------------------------------------
>
> Key: SLING-12469
> URL: https://issues.apache.org/jira/browse/SLING-12469
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
> Reporter: Robert Munteanu
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
>
> Assuming that we have a content package with index definitions stored as
> single files
> {noformat}
> .
> ├── jcr_root
> │ └── _oak_index
> │ ├── .content.xml
> │ └── foo.xml
> └── META-INF
> └── vault
> └── filter.xml
> {noformat}
> WIth the filter listing the individual index definitions
> {noformat}
> <?xml version="1.0" encoding="UTF-8" ?>
> <workspaceFilter version="1.0">
> <filter root="/oak:index/foo" />
> </workspaceFilter>
> {noformat}
> Then the index definitions will not be extracted properly. The root cause is
> that the repository path for the filter is inferred as {{/oak:index/foo.xml}}
> - file extension included. This will cause it to not match the filters.
> Looks like we need to better set the repository paths by following the
> aggregation logic better. IIUC, according to
> https://jackrabbit.apache.org/filevault/config.html#aggregates , foo.xml is
> handled by a FullCoverageAggregator and should have the extension removed.
> Care must be taken to not apply the same logic to the entries handled by
> FileAggregator, whose extension must be kept. This is the case for Tika
> configurations, for instance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
