[
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158233#comment-16158233
]
Tomek Rękawek commented on JCRVLT-199:
--------------------------------------
bq. would it be possible to isolate this mapping in the oak-upgrade module and
use it when we prepare the repository for a composite setup? This way we keep
the change isolated where we need it.
In the current setup, the {{/apps}} and {{/libs}} are not migrated - only the
shared content is, during the first run of the CompositeNodeStore.
We can add an extra step when preparing the initial segmentstore, but I'm not
sure if the oak-upgrade is the best place to put it. Maybe a new oak-run
command (or - more hacky - a groovy script for the oak-run console)?
> Allow mapping some nt:resource nodes to oak:Resource
> ----------------------------------------------------
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality
> is though that for a typical Sling-based setup there will be lots of
> nt:resource nodes in /libs and /apps, and that's were we expect to see
> mounts. Since nt:resource is referenceable any mount-time sanity check will
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and
> /apps to use oak:Resource, I would rather suggest a configuration to
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think
> about this idea before going further. [~tripod] ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
