[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703225#comment-17703225
]
Konrad Windszus commented on JCRVLT-699:
----------------------------------------
bq. and why did it work with filevault 3.4.0 - using the same maven plugin
version?
I don't know yet. Can you help debugging this version and see if
https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L425
kicks in?
I would still go for b) to make it work again with FileVault 3.4.0+. Do you
have a convincing good use case why reproducible builds need to work with
SNAPSHOTs?
In addition it would be good to improve the robustness of copying over
definition from old to new packages, so a fix for b) should be done as well.
> Installation of Sub Packages fails if Maven Reproducible Builds are enabled
> ---------------------------------------------------------------------------
>
> Key: JCRVLT-699
> URL: https://issues.apache.org/jira/browse/JCRVLT-699
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
> Affects Versions: 3.6.6
> Reporter: Stefan Seifert
> Priority: Major
>
> if a container package containing one or multiple sub packages is installed,
> the sub packages automatically get installed as well. if this container
> package is updated with new content but same (snapshot) versions of the sub
> packages, the sub packages reinstalled as well, reflecting the updated
> content of the sub packages
> however, with version 3.6.6 and up, this update of already installed sub
> packages fails, if the sub packages are created with "reproducible builds"
> enabled, which has the effect that the "created" date in the package
> properties remains unchanged
> i've created a small test project to reproduce the problem on
> [https://github.com/stefanseifert/filevault-subpackage-install-issues] -
> steps to reproduce the problem:
> # build project and upload and install the package "app1-all"
> # open {{/content/app1.html}} - it shows "Title 1"
> # change this title in
> {{app1-content/src/main/content/jcr_root/content/app1/.content.xml}} to
> "Title 2"
> # rebuild project and upload and install the package "app1-all"
> # open {{/content/app1.html}} - it still shows "Title 1"
> expected: it should show "Title 2"
> # workaround: re-install the contained sub-package "app1-content" manually,
> then the title is updated
> the problem does not occur if:
> * the property {{project.build.outputTimestamp}} is removed from the project
> * or filevault 3.4.0 is used
> so there was a change between 3.4.0 and 3.6.6 that introduced a problem with
> installing sub packages with reproducible builds enabled. i've debugged a bit
> but was not able to look deeper - but if i put a breakpoint in the
> "PackageTransformer" where it checks whether the package was already
> installed "externally" via {{pkg.isInstalled()}} on the sub packages this
> returns false with 3.4.0 and true with 3.6.6. the vlt:definition node of the
> package shows a mixture of updated content, and properties reflecting the
> previous install, whereas with 3.4.0 only the updated properties are
> displayed.
> i tested the issue with AEMaaCS 2022.11.9850 (using filevault 3.4.0), AEMaaCS
> 2022.12.10488 (using 3.6.6) and 2023.2.11289 (using
> 3.6.9.T20230216120000-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
