[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703106#comment-17703106
]
Konrad Windszus commented on JCRVLT-699:
----------------------------------------
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/kwin/jackrabbit-filevault/blob/a00c6e1551a418d7b35e2bd2850460f77d2d94c6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageManagerImpl.java#L280
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)
