[ https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703106#comment-17703106 ]
Konrad Windszus edited comment on JCRVLT-699 at 3/21/23 9:05 AM: ----------------------------------------------------------------- The issue is that with reproducible build enabled the created date of the package is hard-coded: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/f094341f8244d5d636d992699c762df13b88d84b/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/mojo/GenerateMetadataMojo.java#L982-L986 (derived from the {{build.outputTimestamp}}). Therefore the logic in https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L425 would transfer the metadata from the old to the new package (i.e. keep the lastUnwrapped). Subsequently https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L185 returns true. There are two possible fixes: a) In FileVault never take over existing metadata definition for SNAPSHOTs (requires a new FileVault version at run time) b) In the Maven Plugin never use the hardcoded created date for SNAPSHOTs (just requires a new Maven plugin version at build time). This would effectively disable reproducible builds for SNAPSHOTs (which makes sense from my perspective) [~sseifert] WDYT? was (Author: kwin): The issue is that with reproducible build enabled the created date of the package is hard-coded: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/f094341f8244d5d636d992699c762df13b88d84b/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/mojo/GenerateMetadataMojo.java#L982-L986 (derived from the {{build.outputTimestamp}}). Therefore the logic in https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L425 would transfer the metadata from the old to the new package (i.e. keep the lastUnwrapped). Subsequently https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L185 returns true. There are two possible fixes: a) In FileVault never take over existing metadata definition for SNAPSHOTs (requires a new FileVault version at run time) b) In the Maven Plugin never use the hardcoded created date for SNAPSHOTs (just requires a new Maven plugin version at build time). This would effectively disable reproducible builds for SNAPSHOTs (which makes sense from my perspective) [~sseifert] WDYT? > 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)