[GitHub] [jackrabbit-oak] nit0906 merged pull request #875: OAK-10150 | Add a test for index purge command where the latest OOB i…
nit0906 merged PR #875: URL: https://github.com/apache/jackrabbit-oak/pull/875 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] github-actions[bot] commented on pull request #53: Fix for OAK-4500
github-actions[bot] commented on PR #53: URL: https://github.com/apache/jackrabbit-oak/pull/53#issuecomment-1478812593 This PR is stale because it has been open 24 months with no activity. Remove stale label or comment or this will be closed in 30 days. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] github-actions[bot] commented on pull request #55: OAK-4871 - Multiplexing NodeStore
github-actions[bot] commented on PR #55: URL: https://github.com/apache/jackrabbit-oak/pull/55#issuecomment-1478812566 This PR is stale because it has been open 24 months with no activity. Remove stale label or comment or this will be closed in 30 days. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] stefan-egli commented on a diff in pull request #874: OAK-10149: Rebase may be expensive with many siblings
stefan-egli commented on code in PR #874:
URL: https://github.com/apache/jackrabbit-oak/pull/874#discussion_r1143663923
##
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/AbstractDocumentNodeState.java:
##
@@ -127,6 +128,48 @@ public boolean compareAgainstBaseState(NodeState base,
NodeStateDiff diff) {
}
}
}
+} else if (base instanceof ModifiedNodeState) {
+ModifiedNodeState mBase = (ModifiedNodeState) base;
+if (mBase.getBaseState() == this) {
+// this is the base state of the ModifiedNodeState
+// do a reverse comparison and report the inverse back to
NodeStateDiff
+return mBase.compareAgainstBaseState(this, new NodeStateDiff()
{
Review Comment:
(interesting approach. I'm wondering if it could be useful for other cases)
Would it make sense to move this into its own class and have dedicated test
case for this reversing?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703253#comment-17703253
]
Konrad Windszus edited comment on JCRVLT-699 at 3/21/23 3:18 PM:
-
Thanks for debugging.
Unfortunately there is no checksum available at the time where this check
happens (and calculating it would introduce a major performance loss), so we
can either always drop metadata for overwritten SNAPSHOTs (i.e. always
reinstall, even if not necessary) because even taking into consideration
additional metadata would probably not trigger it or keep the current heuristic
of only considering the createdDate.
There is
https://docs.oracle.com/javase/8/docs/api/java/util/zip/ZipEntry.html#getCrc--
but there is no equivalent in the Content Package Archive interface
(https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Archive.java#L124)
and also iterating through all entries is expensive when you deal with an
arbitrary input stream.
was (Author: kwin):
Thanks for debugging.
Unfortunately there is no checksum available at the time where this check
happens (and calculating it would introduce a major performance loss), so we
can either always drop metadata for overwritten SNAPSHOTs (i.e. always
reinstall, even if not necessary) because even taking into consideration
additional metadata would probably not trigger it or keep the current heuristic
of only considering the createdDate.
> 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
>Assignee: Konrad Windszus
>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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703253#comment-17703253
]
Konrad Windszus commented on JCRVLT-699:
Thanks for debugging.
Unfortunately there is no checksum available at the time where this check
happens (and calculating it would introduce a major performance loss), so we
can either always drop metadata for overwritten SNAPSHOTs (i.e. always
reinstall, even if not necessary) because even taking into consideration
additional metadata would probably not trigger it or keep the current heuristic
of only considering the createdDate.
> 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
>Assignee: Konrad Windszus
>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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703241#comment-17703241
]
Stefan Seifert commented on JCRVLT-699:
---
i debugged the code around
[https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L425]
while installing an affected packages to filevault 3.4.0:
* the code is executed, but def.getCreated() returns null
* looking during the install process at
/etc/packages/app1/app1-content-1.0.0-SNAPSHOT.zip/jcr:content/vlt:definition
shows that jcr:created is indeed missing - but other properties from the just
uploaded package are present, e.g. an updated jcr:description.
* but the uploaded package does contain a create property, probably it's
ignored with filevault 3.4.0
> 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
>Assignee: Konrad Windszus
>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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [jackrabbit-filevault-package-maven-plugin] kwin commented on pull request #91: JCRVLT-699 don't use fix date for SNAPSHOT versions
kwin commented on PR #91: URL: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/91#issuecomment-1477955197 @stefanseifert Can you have a look? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703230#comment-17703230
]
Stefan Seifert commented on JCRVLT-699:
---
ah, i did not read proposal a) exactly, i missed the point you want to disable
it only when a -SNAPSHOT version is used. this should work, and reproducible
build is definitely not required for SNAPSHOT packages. on the other hand, it
feels like a hack to make this distinction in setting the creation date.
> 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
>Assignee: Konrad Windszus
>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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned JCRVLT-699:
--
Assignee: Konrad Windszus
> 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
>Assignee: Konrad Windszus
>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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703225#comment-17703225
]
Konrad Windszus edited comment on JCRVLT-699 at 3/21/23 2:13 PM:
-
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 a) should be done as well.
was (Author: kwin):
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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [jackrabbit-oak] fabriziofortino merged pull request #873: OAK-10146: oak-search-elastic: similarity search does not work for some nodes
fabriziofortino merged PR #873: URL: https://github.com/apache/jackrabbit-oak/pull/873 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] nfsantos commented on a diff in pull request #875: OAK-10150 | Add a test for index purge command where the latest OOB i…
nfsantos commented on code in PR #875:
URL: https://github.com/apache/jackrabbit-oak/pull/875#discussion_r1143181961
##
oak-run/src/test/java/org/apache/jackrabbit/oak/indexversion/LucenePurgeOldIndexVersionTest.java:
##
@@ -176,6 +176,67 @@ public void noDeleteIfNoActiveIndex() throws Exception {
}
}
+// Test the scenario where the latest index is an OOB index but is
disabled, and a lower versioned custom index is actually the only active index
serving queries.
+// Verify that the lower versioned index that is being used for queries
should not get purged.
+@Test
+public void noDeleteIfLatestOOBIndexIsDisabled() throws Exception {
+LogCustomizer custom =
LogCustomizer.forLogger("org.apache.jackrabbit.oak.indexversion.IndexVersionOperation")
+.enable(Level.INFO)
+.create();
+try {
+custom.starting();
+createTestData(false);
+createCustomIndex(TEST_INDEX_PATH, 2, 1, false);
+createCustomIndex(TEST_INDEX_PATH, 3, 0, false);
+createCustomIndex(TEST_INDEX_PATH, 3, 1, false);
+createCustomIndex(TEST_INDEX_PATH, 3, 2, false);
+createCustomIndex(TEST_INDEX_PATH, 3, 3, false);
+createCustomIndex(TEST_INDEX_PATH, 4, 0, false);
+
+NodeStore store = fixture.getNodeStore();
+NodeBuilder rootBuilder = store.getRoot().builder();
+rootBuilder.getChildNode("oak:index")
+.getChildNode("fooIndex-4")
+.setProperty("type", "disabled");
+rootBuilder.getChildNode("oak:index")
+.getChildNode("fooIndex-3-custom-3")
+.setProperty("type", "disabled")
+.setProperty(":originalType", "lucene");
+store.merge(rootBuilder, EmptyHook.INSTANCE, CommitInfo.EMPTY);
+
+addMockHiddenOakMount(fixture.getNodeStore(),
Arrays.asList("fooIndex-3-custom-1", "fooIndex-3-custom-2"));
Review Comment:
Since OAK now requires Java 11 as a baseline, we can now use the List.of()
factory method which was introduced in Java 9.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703137#comment-17703137
]
Stefan Seifert commented on JCRVLT-699:
---
and why did it work with filevault 3.4.0 - using the same maven plugin version?
> 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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703136#comment-17703136
]
Stefan Seifert commented on JCRVLT-699:
---
i think in general having the reproducible build feature in the package plugin
working as it is is a good thing and should be kept, so i do not favor b)
the check in
[https://github.com/apache/jackrabbit-filevault/blob/870ac10e12a767c6f4a15e4d9d76fe88523ac97f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L425]
is very simplistic by only looking at the created date. wouldn't it be better
to
* actually compare the package content, not sure if this is possible e.g. by
comparing a hash value
* or to always replace the package if a -SNAPSHOT version is used?
so a) sounds like a good solution to me, although it takes longer to get
updated in all affected runtimes.
> 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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [jackrabbit-oak] nit0906 opened a new pull request, #875: OAK-10150 | Add a test for index purge command where the latest OOB i…
nit0906 opened a new pull request, #875: URL: https://github.com/apache/jackrabbit-oak/pull/875 …ndex is disabled and the queries are served by a lower versioned index -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703106#comment-17703106
]
Konrad Windszus edited comment on JCRVLT-699 at 3/21/23 9:04 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/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 -
[jira] [Commented] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
[
https://issues.apache.org/jira/browse/JCRVLT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-699:
---
Issue Type: Bug (was: Improvement)
> 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.T2023021612-0a9b076a) - but i assume it can be reproduced with
> sling only as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
