[
https://issues.apache.org/jira/browse/JCRVLT-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470699#comment-17470699
]
Konrad Windszus commented on JCRVLT-584:
----------------------------------------
bq. Question is whether the "old" behavior (just assigning new UUIDs) is
somewhat reasonable and ok to rely on...
For me silently ignoring this error is wrong and may lead to subtle follow-up
errors. Therefore I would strongly suggest to fail loudly (with a reasonable
exception message) so that this package (which was obviously manually
modified/created) can be fixed.
> 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)
