[
https://issues.apache.org/jira/browse/JCRVLT-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470681#comment-17470681
]
Julian Reschke commented on JCRVLT-584:
---------------------------------------
Sorry for the earlier misleading comment.
What we seem to have here is a content package where the same jcr:uuid is
indeed repeating on multiple jcr:content nodes - maybe a copy-and-paste error
by the author.
With vault 3.4.0, this imports, and some of the nodes get new UUIDs.
With 3.5.8 in local testing, vault seems to remove the conflicting nodes during
import ("works as designed", I guess).
With 3.5.8 on a customer system, the package import fails. We're still trying
to get a useful log for this case.
> Forcing UUID on packages may break previously installable packages
> ------------------------------------------------------------------
>
> Key: JCRVLT-584
> URL: https://issues.apache.org/jira/browse/JCRVLT-584
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
> Affects Versions: 3.5.8
> Reporter: Dominik Süß
> Priority: Major
>
> The Changes of JCRVLT-551 introduce a breaking behavior for existing packages
> that previously installed fine if those don't meet referential integrity.
> While the intention of the improvement is clear it can lead to unexpectedly
> failing installations even if referential integrity wasn't intended. This
> explicitly happens for packages created by a vlt export which would bundle up
> created jcr:uuids.
> As this seems not to be an isolated scenario (verified to not occur on an
> isolated case) the proposed solution would be to make referential integrity a
> package property where the default behavior (strict or relaxed on enforcing
> referential integrity) may be configured system wide and explicit behavior
> may be defined via the package properties (therefore the intend of
> referential integrity can be marked and controlled).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
