[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853381#comment-17853381 ] Stefan Seifert commented on JCRVLT-756: --- thanks for the quick reaction [~bisswanger] , i can confirm the problem is solved in SDK release! > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Priority: Minor (was: Critical) ok, thanks for cross-checking, i will get in touch with support. lowering priority here. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852828#comment-17852828 ] Stefan Seifert commented on JCRVLT-756: --- i've seen there are a lot of ITs around sub packages already in [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core-it/vault-core-integration-tests/src/main/java/org/apache/jackrabbit/vault/packaging/integration/SubPackagesIT.java] - i tried uploading different "all" packages to AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 and they all fail. i'm not sure if it's really a problem related to the vault impl, but there was the change mentioned above exactly between those two versions. maybe someone more knowledgeable in the vault impl then myself can take a look to get a better idea in which area the problem is located. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852750#comment-17852750 ] Stefan Seifert commented on JCRVLT-756: --- the two tickets which changed the vlt behavior between those two commits are JCRVLT-745 and JCRVLT-751 - but i do not see how they should break the install behavior in this way. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Description: i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i've attached log files with the package install procedure with both those versions. was: i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i'm attached log files with the package install procedure with both those versions. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Attachment: vault_installer_2024.5.16461.20240524T172309Z-240500.log vault_installer_2024.5.16544.20240530T165853Z-240500.log > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i'm attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-756) Sub packages contained in "all" package no longer installed
Stefan Seifert created JCRVLT-756: - Summary: Sub packages contained in "all" package no longer installed Key: JCRVLT-756 URL: https://issues.apache.org/jira/browse/JCRVLT-756 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Affects Versions: 3.7.4 Reporter: Stefan Seifert Attachments: vault_installer_2024.5.16461.20240524T172309Z-240500.log, vault_installer_2024.5.16544.20240530T165853Z-240500.log i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i'm attached log files with the package install procedure with both those versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.3.6
+1 (non-binding) with [INFO] [INFO] Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) [INFO] OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows" [INFO] Java version: 11.0.20, vendor: Oracle Corporation, runtime: C:\java\jdk-11.0.20 [INFO] MAVEN_OPTS: [INFO] [INFO] ALL CHECKS OK [INFO] stefan
RE: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.3.4
+1 (non-binding) stefan
adaptTo() 2023: Agenda online
Dear adaptTo() Community, Exciting news! The agenda for adaptTo() 2023, Europe's leading AEM Developer Conference, has been announced! https://adapt.to/2023/schedule Tickets are still available: https://adapt.to/tickets Your adaptTo() Conference Team
adaptTo() 2023: Agenda online
Dear adaptTo() Community, Exciting news! The agenda for adaptTo() 2023, Europe's leading AEM Developer Conference, has been announced! https://adapt.to/2023/schedule Tickets are still available: https://adapt.to/tickets Your adaptTo() Conference Team
adaptTo() 2023: Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another three weeks. The final deadline is the 21st of April. If you would like to be a speaker, see https://adapt.to/cfp - or if you know someone who should apply to be a speaker, please send them our way! Early Bird Tickets are still available until the 31st of May. And we have a special offer for loyal attendees. https://adapt.to/tickets As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. Your adaptTo() Conference Team
adaptTo() 2023: Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another three weeks. The final deadline is the 21st of April. If you would like to be a speaker, see https://adapt.to/cfp - or if you know someone who should apply to be a speaker, please send them our way! Early Bird Tickets are still available until the 31st of May. And we have a special offer for loyal attendees. https://adapt.to/tickets As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. Your adaptTo() Conference Team
[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)
[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] [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)
[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=17702879#comment-17702879
]
Stefan Seifert commented on JCRVLT-699:
---
(accidentally used the wrong ticket type, should be "bug", but i'm not allowed
to change it)
> 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: Improvement
> 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] [Created] (JCRVLT-699) Installation of Sub Packages fails if Maven Reproducible Builds are enabled
Stefan Seifert created JCRVLT-699:
-
Summary: 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: Improvement
Components: vlt
Affects Versions: 3.6.6
Reporter: Stefan Seifert
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)
adaptTo() 2023: Call for Papers, Early Bird Tickets
Dear adaptTo() Community, Europe's leading AEM Developer conference is back, and in-person! It will take place on 25th-27th September 2023 at the Kulturbrauerei in Berlin, Germany. The adaptTo() is a community event. Therefore we encourage everyone to participate. By covering various facets of the overall topics Adobe Experience Manager, Adobe Experience Cloud, and the underlying OSS projects Apache Sling, Apache Felix, and Apache Jackrabbit Oak, we set starting points for the community to discuss and interact. The Call for Papers has officially opened and you have now the chance to shape adaptTo(). Submissions are being accepted until 1st of April 2023. https://adapt.to/cfp Early Bird Tickets for the on-site adaptTo() 2023 are available now! This year, we also offer a special Loyalty Discount for previous attendees. https://adapt.to/tickets Your adaptTo() Conference Team
adaptTo() 2023: Call for Papers, Early Bird Tickets
Dear adaptTo() Community, Europe's leading AEM Developer conference is back, and in-person! It will take place on 25th-27th September 2023 at the Kulturbrauerei in Berlin, Germany. The adaptTo() is a community event. Therefore we encourage everyone to participate. By covering various facets of the overall topics Adobe Experience Manager, Adobe Experience Cloud, and the underlying OSS projects Apache Sling, Apache Felix, and Apache Jackrabbit Oak, we set starting points for the community to discuss and interact. The Call for Papers has officially opened and you have now the chance to shape adaptTo(). Submissions are being accepted until 1st of April 2023. https://adapt.to/cfp Early Bird Tickets for the on-site adaptTo() 2023 are available now! This year, we also offer a special Loyalty Discount for previous attendees. https://adapt.to/tickets Your adaptTo() Conference Team
adaptTo() 2023: Call for Papers, Early Bird Tickets
Dear adaptTo() Community, Europe's leading AEM Developer conference is back, and in-person! It will take place on 25th-27th September 2023 at the Kulturbrauerei in Berlin. The adaptTo() is a community event. Therefore we encourage everyone to participate. By covering various facets of the overall topics Adobe Experience Manager, Adobe Experience Cloud, and the underlying OSS projects Apache Sling, Apache Felix, and Apache Jackrabbit Oak, we set starting points for the community to discuss and interact. The Call for Papers has officially opened and you have now the chance to shape adaptTo(). Submissions are being accepted until 1st of April 2023. https://adapt.to/cfp Early Bird Tickets for the on-site adaptTo() 2023 are available now! This year, we also offer a special Loyalty Discount for previous attendees. https://adapt.to/tickets Your adaptTo() Conference Team
adaptTo() 2023: Call for Papers, Early Bird Tickets
Dear adaptTo() Community, Europe's leading AEM Developer conference is back, and in-person! It will take place on 25th-27th September 2023 at the Kulturbrauerei in Berlin. The adaptTo() is a community event. Therefore we encourage everyone to participate. By covering various facets of the overall topics Adobe Experience Manager, Adobe Experience Cloud, and the underlying OSS projects Apache Sling, Apache Felix, and Apache Jackrabbit Oak, we set starting points for the community to discuss and interact. The Call for Papers has officially opened and you have now the chance to shape adaptTo(). Submissions are being accepted until 1st of April 2023. https://adapt.to/cfp Early Bird Tickets for the on-site adaptTo() 2023 are available now! This year, we also offer a special Loyalty Discount for previous attendees. https://adapt.to/tickets Your adaptTo() Conference Team
RE: 180 open PRs on Github
hello jörg. this sounds like a job that should be automated - e.g. using the stale github action [2]. usage example [3]. stefan [2] https://github.com/actions/stale [3] https://github.com/mojohaus/versions-maven-plugin/blob/master/.github/workflows/stale.yml >-Original Message- >From: Jörg Hoh >Sent: Wednesday, August 10, 2022 11:56 AM >To: oak-dev@jackrabbit.apache.org >Subject: 180 open PRs on Github > >Hi, > >On the jackrabbit-oak github repository [1] we currently have 180 open PRs. >The oldest is from 2013 (!) and many of them are of course no longer able >to merge. > >I would like to start some cleanup and close all PRs older than 2020. The >assumption is that these PRs are no longer relevant, because they have been >already addressed in one way or the other. But in any way additional effort >is required to either fix any merge conflicts or check if the PR is still >relevant. > >I suggest this approach: >* add a comment to each of these open PRs older than 2020, and asking if >this PR is still relevant and should be merged. In that case the owner >should revisit the PR and drive it towards merging. >* as a 2nd step I would close all of these PRs which did not receive any >feedback for the update. This would be in around today + 2 months, which >should give everyone enough time to at least put a short comment indicating >the importance of this PR. > >WDYT? > >I would create a ticket for it and also carry out this task. > >(If you are reading this and remember some old PRs of you still being open >but no longer required, feel free to close them already.) > >Jörg > > >[1] https://github.com/apache/jackrabbit-oak > >-- >Cheers, >Jörg Hoh, > >https://cqdump.joerghoh.de >Twitter: @joerghoh
RE: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.3.0
+1 (non-binding) validated the release candidate and tested it with projects stefan
RE: [VOTE] Release Apache Jackrabbit FileVault 3.6.0
+1 (non-binding) tested with test projects stefan
RE: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.2.0
hello konrad. i tested the new plugin with some of our projects and discovered a new isse https://issues.apache.org/jira/browse/JCRVLT-564 did not had time to look into details, but build was fine with plugin 1.1.8 stefan >-Original Message- >From: Konrad Windszus >Sent: Friday, October 8, 2021 8:39 AM >To: dev@jackrabbit.apache.org >Subject: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin >1.2.0 > >Hello, > >A candidate for the Jackrabbit FileVault Package Maven Plugin 1.2.0 release >is available at: >https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven- >plugin/1.2.0/ > >The release candidate is a zip archive of the sources in: >https://github.com/apache/jackrabbit-filevault-package-maven- >plugin/tree/filevault-package-maven-plugin-1.2.0/ > >The SHA1 checksum of the archive is >f9ab26a4670850e0e9694a486f2700e236a99fe3 > >The release notes can be found in JIRA at >https://issues.apache.org/jira/projects/JCRVLT/versions/12350257 > >The command for running automated checks against this release candidate is: >$ sh check-release.sh filevault-plugin 1.2.0 >f9ab26a4670850e0e9694a486f2700e236a99fe3 > >A staged Maven repository is available for review at: >https://repository.apache.org/content/repositories/orgapachejackrabbit-1557 > >Please vote on releasing this package as Apache Jackrabbit FileVault >Package Maven Plugin 1.2.0. >The vote is open for a minimum of 72 hours during business days and passes >if a majority of at least three +1 Jackrabbit PMC votes are cast. >The vote fails if not enough votes are cast after 1 week (5 business days). > >[ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven >Plugin 1.2.0 >[ ] -1 Do not release this package because... > >Thanks, >Konrad
[jira] [Created] (JCRVLT-564) jackrabbit-packagetype validation fails for content package with OSGi configurations
Stefan Seifert created JCRVLT-564:
-
Summary: jackrabbit-packagetype validation fails for content
package with OSGi configurations
Key: JCRVLT-564
URL: https://issues.apache.org/jira/browse/JCRVLT-564
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.2.0
Reporter: Stefan Seifert
scenario:
* checkout
[https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues]
* update filevault-package-maven-plugin to 1.2.0
* try to build the module {{content-packages/osgi-config}}
* build fails - but package is imho correct and build was fine with version
1.1.8
validation errors:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!", filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig,
nodePath=/apps/osgi-config-sample/core-osgiconfig
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config\io.wcm.caconfig.extensions.persistence.impl.PagePersistenceStrategy.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config/io.wcm.caconfig.extensions.persistence.impl.PagePersistenceStrategy.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author\com.adobe.cq.dam.processor.nui.impl.workflow.CustomDamWorkflowRunnerImpl.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author/com.adobe.cq.dam.processor.nui.impl.workflow.CustomDamWorkflowRunnerImpl.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author\com.day.cq.mailer.DefaultMailService.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author/com.day.cq.mailer.DefaultMailService.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author\com.day.cq.workflow.impl.email.EMailNotificationService.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author/com.day.cq.workflow.impl.email.EMailNotificationService.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author\io.wcm.handler.mediasource.dam.impl.dynamicmedia.DynamicMediaSupportServiceImpl.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author/io.wcm.handler.mediasource.dam.impl.dynamicmedia.DynamicMediaSupportServiceImpl.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author\org.apache.felix.hc.core.impl.servlet.HealthCheckExecutorServlet~health.cfg.json,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author/org.apache.felix.hc.core.impl.servlet.HealthCheckExecutorServlet~health.cfg.json
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but OSGi bundles/configurations
and subpackages!",
filePath=jcr_root\apps\osgi-config-sample\core-osgiconfig\config.author.dev,
nodePath=/apps/osgi-config-sample/core-osgiconfig/config.author.dev
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
'CONTAINER' is not supposed to contain anything but O
adaptTo() 2021 - Only 3 weeks left: get your ticket!
Hello everyone, We're excited to see some of the best Adobe experts and AEM developers and the best attendees at adaptTo() 2021. We expect you from 27.-29. Sept. to Europe's leading AEM developer conference. Top-class speakers and the most exciting topics are guaranteed. If you don't have a ticket yet, you can order a ticket here: https://adapt.to/tickets adaptTo() 2021 | 27.-29. Sept. Europe's leading AEM Developer Conference We will shortly be updating our agenda with the panel discussions and meet-the-expert sessions. Follow us on https://adapt.to/linkedin or https://twitter.com/adaptto @adaptto to keep up to date. Kind regards from the adaptTo() Team, Stefan
adaptTo() 2021 - Only 3 weeks left: get your ticket!
Hello everyone, We're excited to see some of the best Adobe experts and AEM developers and the best attendees at adaptTo() 2021. We expect you from 27.-29. Sept. to Europe's leading AEM developer conference. Top-class speakers and the most exciting topics are guaranteed. If you don't have a ticket yet, you can order a ticket here: https://adapt.to/tickets adaptTo() 2021 | 27.-29. Sept. Europe's leading AEM Developer Conference We will shortly be updating our agenda with the panel discussions and meet-the-expert sessions. Follow us on https://adapt.to/linkedin or https://twitter.com/adaptto @adaptto to keep up to date. Kind regards from the adaptTo() Team, Stefan
[jira] [Commented] (JCRVLT-556) jackrabbit-packagetype validator wrongly complains about OSGI configurations in tools/config path
[
https://issues.apache.org/jira/browse/JCRVLT-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409127#comment-17409127
]
Stefan Seifert commented on JCRVLT-556:
---
i've created a simple test case:
https://github.com/apache/jackrabbit-filevault/pull/165
but i'm not sure if it's too synthetic and we probably need a full integration
test here (but i did not find a better example i could adapt looking at the
other test cases)
> jackrabbit-packagetype validator wrongly complains about OSGI configurations
> in tools/config path
> -
>
> Key: JCRVLT-556
> URL: https://issues.apache.org/jira/browse/JCRVLT-556
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: validation
>Affects Versions: 3.5.2
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.5.4
>
>
> scenario: content package project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> compile package with filevault-package-maven-plugin 1.1.9-SNAPSHOT using
> filevault 3.5.2
> validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config, line=3
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config/jcr:content, line=8
> {noformat}
> but this is wrong, as the folder does not contain any OSGi configurations or
> bundle. it simply has the name /config - but this surely is not enough to
> "prove" it's illegal in a CONTENT package? any CMS user may create a path
> with a name like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-556) jackrabbit-packagetype validator wrongly complains about OSGI configurations in tools/config path
[
https://issues.apache.org/jira/browse/JCRVLT-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408682#comment-17408682
]
Stefan Seifert edited comment on JCRVLT-556 at 9/2/21, 8:39 AM:
there is a conceptual problem in
https://github.com/apache/jackrabbit-filevault/blob/d759ef289e6f46c652288af8ddc6d5cb42da3281/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/spi/impl/PackageTypeValidator.java#L108
i've debugged, and the input to this method is (in my case on windows):
{{content\filevaultsample\en\tools\config\.content.xml}}
ValidationExecutor.filePathToNodePath translates this to
{{/content/filevaultsample/en/tools/config/.content.xml}} - which is imho not
correct, because the ".content.xml" is not part of the node path, only part of
the file system layout.
this (wrong) node path than is flagged as "this is an osgi config", because if
it would be something other than .content.xml it's likely an osgi config.
i could provide a PR to add asserts for paths like this and fix the regex
excluding it, but is it correct that ValidationExecutor.filePathToNodePath
translates the file system path this way?
was (Author: sseif...@pro-vision.de):
there is a conceptual problem in
https://github.com/apache/jackrabbit-filevault/blob/d759ef289e6f46c652288af8ddc6d5cb42da3281/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/spi/impl/PackageTypeValidator.java#L108
i've debugged, and the input to this method is (in my case on windows):
{{content\filevaultsample\en\tools\config\.content.xml}}
ValidationExecutor.filePathToNodePath translates this to
{{/content/filevaultsample/en/tools/config/.content.xml}} - which is imho not
correct, because the ".content.xml" is not part of the node path, only part of
the file system layout.
this (wrong) node path than is flagged as "this is an osgi config", because if
it would be something other than .content.xml it's likely an osgi config.
i could provide a PR to add assets for paths like this and fix the regex
excluding it, but is it correct that ValidationExecutor.filePathToNodePath
translates the file system path this way?
> jackrabbit-packagetype validator wrongly complains about OSGI configurations
> in tools/config path
> -
>
> Key: JCRVLT-556
> URL: https://issues.apache.org/jira/browse/JCRVLT-556
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: validation
>Affects Versions: 3.5.2
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.5.4
>
>
> scenario: content package project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> compile package with filevault-package-maven-plugin 1.1.9-SNAPSHOT using
> filevault 3.5.2
> validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config, line=3
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config/jcr:content, line=8
> {noformat}
> but this is wrong, as the folder does not contain any OSGi configurations or
> bundle. it simply has the name /config - but this surely is not enough to
> "prove" it's illegal in a CONTENT package? any CMS user may create a path
> with a name like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-556) jackrabbit-packagetype validator wrongly complains about OSGI configurations in tools/config path
[
https://issues.apache.org/jira/browse/JCRVLT-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408682#comment-17408682
]
Stefan Seifert commented on JCRVLT-556:
---
there is a conceptual problem in
https://github.com/apache/jackrabbit-filevault/blob/d759ef289e6f46c652288af8ddc6d5cb42da3281/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/spi/impl/PackageTypeValidator.java#L108
i've debugged, and the input to this method is (in my case on windows):
{{content\filevaultsample\en\tools\config\.content.xml}}
ValidationExecutor.filePathToNodePath translates this to
{{/content/filevaultsample/en/tools/config/.content.xml}} - which is imho not
correct, because the ".content.xml" is not part of the node path, only part of
the file system layout.
this (wrong) node path than is flagged as "this is an osgi config", because if
it would be something other than .content.xml it's likely an osgi config.
i could provide a PR to add assets for paths like this and fix the regex
excluding it, but is it correct that ValidationExecutor.filePathToNodePath
translates the file system path this way?
> jackrabbit-packagetype validator wrongly complains about OSGI configurations
> in tools/config path
> -
>
> Key: JCRVLT-556
> URL: https://issues.apache.org/jira/browse/JCRVLT-556
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: validation
> Affects Versions: 3.5.2
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.5.4
>
>
> scenario: content package project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> compile package with filevault-package-maven-plugin 1.1.9-SNAPSHOT using
> filevault 3.5.2
> validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config, line=3
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config/jcr:content, line=8
> {noformat}
> but this is wrong, as the folder does not contain any OSGi configurations or
> bundle. it simply has the name /config - but this surely is not enough to
> "prove" it's illegal in a CONTENT package? any CMS user may create a path
> with a name like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-538) PackageTypeValidator: Improve robustness of bundle/configuration and subpackage detection
[ https://issues.apache.org/jira/browse/JCRVLT-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408672#comment-17408672 ] Stefan Seifert commented on JCRVLT-538: --- fix version should be 3.5.2 for this ticket & it's resolved? > PackageTypeValidator: Improve robustness of bundle/configuration and > subpackage detection > - > > Key: JCRVLT-538 > URL: https://issues.apache.org/jira/browse/JCRVLT-538 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.5.4 > > > The regular expressions are very complicated and should be simplified. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-556) jackrabbit-packagetype validator wrongly complains about OSGI configurations in tools/config path
[
https://issues.apache.org/jira/browse/JCRVLT-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408663#comment-17408663
]
Stefan Seifert commented on JCRVLT-556:
---
if i switch back to filevault-package-maven-plugin 1.1.8 the problem does not
occur (which is based on filevault 3.5.0).
will try to come up with a PR.
> jackrabbit-packagetype validator wrongly complains about OSGI configurations
> in tools/config path
> -
>
> Key: JCRVLT-556
> URL: https://issues.apache.org/jira/browse/JCRVLT-556
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: validation
>Affects Versions: 3.5.2
> Reporter: Stefan Seifert
>Priority: Major
>
> scenario: content package project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> compile package with filevault-package-maven-plugin 1.1.9-SNAPSHOT using
> filevault 3.5.2
> validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config, line=3
> [ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type
> 'CONTENT' is not supposed to contain OSGi bundles or configurations!",
> filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
> nodePath=/content/filevaultsample/en/tools/config/jcr:content, line=8
> {noformat}
> but this is wrong, as the folder does not contain any OSGi configurations or
> bundle. it simply has the name /config - but this surely is not enough to
> "prove" it's illegal in a CONTENT package? any CMS user may create a path
> with a name like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
RE: [VOTE} Release Apache Jackrabbit FileVault 3.5.2
hello konrad. release validates fine, however i found an issue testing it with my usual test project, details reported in https://issues.apache.org/jira/browse/JCRVLT-556 stefan >-Original Message- >From: Konrad Windszus >Sent: Wednesday, September 1, 2021 7:33 PM >To: dev@jackrabbit.apache.org >Subject: [VOTE} Release Apache Jackrabbit FileVault 3.5.2 > >Hi, >A candidate for the Jackrabbit FileVault 3.5.2 release is available at: > >https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.5.2/ > >The release candidate is a zip archive of the sources in: > >https://github.com/apache/jackrabbit-filevault/tree/jackrabbit-filevault- >3.5.2/ > >The release notes can be found in JIRA at >https://issues.apache.org/jira/projects/JCRVLT/versions/12350211 > >The command for running automated checks against this release candidate is: >$ sh check-release.sh filevault 3.5.2 >c5bce16a7ba9ddc42d85ec4d297d4c3b981594d4 >(leveraging the script from >https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh) > >A staged Maven repository is available for review at: > >https://repository.apache.org/content/repositories/orgapachejackrabbit-1552 > >Please vote on releasing this package as Apache Jackrabbit FileVault 3.5.2. >The vote is open for a minimum of 72 hours during business days and passes >if a majority of at least three +1 Jackrabbit PMC votes are cast. >The vote fails if not enough votes are cast after 1 week (5 business days). > >[ ] +1 Release this package as Apache Jackrabbit FileVault 3.5.2 >[ ] -1 Do not release this package because... > >Regards, >Konrad
[jira] [Created] (JCRVLT-556) jackrabbit-packagetype validator wrongly complains about OSGI configurations in tools/config path
Stefan Seifert created JCRVLT-556:
-
Summary: jackrabbit-packagetype validator wrongly complains about
OSGI configurations in tools/config path
Key: JCRVLT-556
URL: https://issues.apache.org/jira/browse/JCRVLT-556
Project: Jackrabbit FileVault
Issue Type: Bug
Components: validation
Affects Versions: 3.5.2
Reporter: Stefan Seifert
scenario: content package project
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
compile package with filevault-package-maven-plugin 1.1.9-SNAPSHOT using
filevault 3.5.2
validation fails with:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type 'CONTENT'
is not supposed to contain OSGi bundles or configurations!",
filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
nodePath=/content/filevaultsample/en/tools/config, line=3
[ERROR] ValidationViolation: "jackrabbit-packagetype: Package of type 'CONTENT'
is not supposed to contain OSGi bundles or configurations!",
filePath=jcr_root\content\filevaultsample\en\tools\config\.content.xml,
nodePath=/content/filevaultsample/en/tools/config/jcr:content, line=8
{noformat}
but this is wrong, as the folder does not contain any OSGi configurations or
bundle. it simply has the name /config - but this surely is not enough to
"prove" it's illegal in a CONTENT package? any CMS user may create a path with
a name like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
adaptTo() 2021 - Agenda and Speakers
Hi everyone, we are happy to present you the official adaptTo() 2021 agenda for our virtual online conference: https://adapt.to/schedule This year's speakers are leading developers and architects in their field: https://adapt.to/speaker Don't have a ticket yet? Here we go - we have also discounted loyalty tickets for participants from previous years. Take a look to the ticket shop. https://adapt.to/tickets We are looking forward to welcoming you in our virtual online conference, there will be lots of possibilities to get in touch with the speakers and other participants. Kind regards on behalf of the adaptTo() Team Stefan
adaptTo() 2021 - Agenda and Speakers
Hi everyone, we are happy to present you the official adaptTo() 2021 agenda for our virtual online conference: https://adapt.to/schedule This year's speakers are leading developers and architects in their field: https://adapt.to/speaker Don't have a ticket yet? Here we go - we have also discounted loyalty tickets for participants from previous years. Take a look to the ticket shop. https://adapt.to/tickets We are looking forward to welcoming you in our virtual online conference, there will be lots of possibilities to get in touch with the speakers and other participants. Kind regards on behalf of the adaptTo() Team Stefan
[jira] [Commented] (JCRVLT-528) filevault-package-maven-plugin:validate-files reports nodetype related errors validate-package does not
[
https://issues.apache.org/jira/browse/JCRVLT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361460#comment-17361460
]
Stefan Seifert commented on JCRVLT-528:
---
thanks!
> filevault-package-maven-plugin:validate-files reports nodetype related errors
> validate-package does not
> ---
>
> Key: JCRVLT-528
> URL: https://issues.apache.org/jira/browse/JCRVLT-528
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.6
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: package-maven-plugin-1.1.10
>
>
> scenario: use content package sample project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
> and execute {{mvn clean verify}} (which calls validate-package goal) - all
> is well, package validation completes successfully.
> now execute on the same project with {{mvn clean test}} (which calls
> validate-files goal) - this time the validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
> 'sling:resourceType' [String] is not allowed in node with potential default
> types [nt:folder]: No applicable property definition found for name and
> type!", filePath=jcr_root\conf\filevaultsample\settings\.content.xml,
> nodePath=/conf/filevaultsample/settings, line=4, column=40
> {noformat}
> why this? it's the same package and the same validators configuration.
> furthermore, the package content is downloaded from package manager and not
> created manually, so it should be consistent.
> same problem can be reproduced with more validation differences with:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-528) filevault-package-maven-plugin:validate-files reports errors validate-package does not
[
https://issues.apache.org/jira/browse/JCRVLT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360390#comment-17360390
]
Stefan Seifert commented on JCRVLT-528:
---
lgtm! - tested it successfully with two projects
> filevault-package-maven-plugin:validate-files reports errors validate-package
> does not
> --
>
> Key: JCRVLT-528
> URL: https://issues.apache.org/jira/browse/JCRVLT-528
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.6
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: package-maven-plugin-1.1.10
>
>
> scenario: use content package sample project
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
> and execute {{mvn clean verify}} (which calls validate-package goal) - all
> is well, package validation completes successfully.
> now execute on the same project with {{mvn clean test}} (which calls
> validate-files goal) - this time the validation fails with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
> 'sling:resourceType' [String] is not allowed in node with potential default
> types [nt:folder]: No applicable property definition found for name and
> type!", filePath=jcr_root\conf\filevaultsample\settings\.content.xml,
> nodePath=/conf/filevaultsample/settings, line=4, column=40
> {noformat}
> why this? it's the same package and the same validators configuration.
> furthermore, the package content is downloaded from package manager and not
> created manually, so it should be consistent.
> same problem can be reproduced with more validation differences with:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-528) filevault-package-maven-plugin:validate-files reports errors validate-package does not
Stefan Seifert created JCRVLT-528:
-
Summary: filevault-package-maven-plugin:validate-files reports
errors validate-package does not
Key: JCRVLT-528
URL: https://issues.apache.org/jira/browse/JCRVLT-528
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.6
Reporter: Stefan Seifert
scenario: use content package sample project
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
and execute {{mvn clean verify}} (which calls validate-package goal) - all is
well, package validation completes successfully.
now execute on the same project with {{mvn clean test}} (which calls
validate-files goal) - this time the validation fails with:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
'sling:resourceType' [String] is not allowed in node with potential default
types [nt:folder]: No applicable property definition found for name and type!",
filePath=jcr_root\conf\filevaultsample\settings\.content.xml,
nodePath=/conf/filevaultsample/settings, line=4, column=40
{noformat}
why this? it's the same package and the same validators configuration.
furthermore, the package content is downloaded from package manager and not
created manually, so it should be consistent.
same problem can be reproduced with more validation differences with:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
RE: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.1.8
+1 (non-binding) - verified it & tested it locally with some test projects [INFO] Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) [INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" [INFO] Java version: 11.0.9, vendor: Oracle Corporation, runtime: C:\java\jdk-11.0.9 [INFO] MAVEN_OPTS: -Xmx2048M stefan >-Original Message- >From: Konrad Windszus >Sent: Wednesday, June 2, 2021 11:45 AM >To: dev@jackrabbit.apache.org >Subject: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin >1.1.8 > >Hello, > >A candidate for the Jackrabbit FileVault Package Maven Plugin 1.1.8 release >is available at: >https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven- >plugin/1.1.8/ > >The release candidate is a zip archive of the sources in: >https://github.com/apache/jackrabbit-filevault-package-maven- >plugin/tree/filevault-package-maven-plugin-1.1.8/ > >The SHA1 checksum of the archive is >40081dde2fdd38fa80391493cd3c1366bbd3de9b > >The command for running automated checks against this release candidate is: >$ sh check-release.sh filevault-plugin 1.1.8 >40081dde2fdd38fa80391493cd3c1366bbd3de9b > >A staged Maven repository is available for review at: >https://repository.apache.org/content/repositories/orgapachejackrabbit-1547 > >Please vote on releasing this package as Apache Jackrabbit FileVault >Package Maven Plugin 1.1.8. >The vote is open for a minimum of 72 hours during business days and passes >if a majority of at least three +1 Jackrabbit PMC votes are cast. >The vote fails if not enough votes are cast after 1 week (5 business days). > >[ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven >Plugin 1.1.8 >[ ] -1 Do not release this package because... > >Konrad
adaptTo() 2021 - Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another three weeks. The new deadline is April 23rd. So, if you would like to be a speaker, please visit https://adapt.to/cfp - and/or if you know any other potential speakers, please send them our way! I would also like to use this opportunity to remind you that Early Bird tickets are still available. Go to https://adapt.to/tickets before May 31st to take advantage of this offer. As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. Kind regards on behalf of the adaptTo() Team, Stefan
adaptTo() 2021 - Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another three weeks. The new deadline is April 23rd. So, if you would like to be a speaker, please visit https://adapt.to/cfp - and/or if you know any other potential speakers, please send them our way! I would also like to use this opportunity to remind you that Early Bird tickets are still available. Go to https://adapt.to/tickets before May 31st to take advantage of this offer. As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. Kind regards on behalf of the adaptTo() Team, Stefan
adaptTo() 2021: Tickets now available / Call for Papers open
| Europe's leading AEM developer conference | 27th - 29th September 2021 Dear adaptTo() Community, This year, adaptTo() 2021 is planned as a hybrid approach with a combination of on-site presence and virtual attendees. However, it's currently unclear if the worldwide pandemic situation will have calmed down in September and unrestricted travel is allowed again. So we've started the ticket sales with virtual attendee tickets only in February. We plan to offer on-site tickets in summer and will offer an "upgrade path" for ticket buyers that want to change their virtual ticket into an on-site ticket. Ticket shop: https://adapt.to/tickets Take advantage of a discount: * Get an early bird discount until end of May. * Benefit from a referral discount of up to 12€ on the booked ticket price for each new participant you recommend when booking their ticket - see https://adapt.to/referral-bonus * Loyalty ticket: Attendees of any previous adaptTo() conference (2011-2020) qualify for a special discount of up to 20%. Please send us a mail to i...@adapt.to to get a code. Call for papers has started - if you want to submit a talk please go to https://adapt.to/cfp For more information, please visit http://adapt.to/ or share your thoughts via mail at i...@adapt.to or #adaptto or at https://adapt.to/linkedin We look forward to your participation. Kind regards from the adaptTo() Team, Stefan
RE: Release Jackrabbit FileVault 3.4.8 and FileVault Package Maven Plugin 1.1.6
i've the same problem after clearing the relevant parts of my local maven repo. strange that the version is missing from the maven central metadata, as the artifacts itself are there: https://repo.maven.apache.org/maven2/javax/jcr/jcr/2.0/ on the public adobe repo the metadata is complete, that's maybe the reason it works for some https://repo.adobe.com/nexus/content/groups/public/javax/jcr/jcr/maven-metadata.xml stefan >-Original Message- >From: Robert Munteanu >Sent: Tuesday, January 12, 2021 10:09 AM >To: dev@jackrabbit.apache.org >Subject: Re: Release Jackrabbit FileVault 3.4.8 and FileVault Package Maven >Plugin 1.1.6 > >Hi, > >On Mon, 2021-01-11 at 20:44 +0100, Konrad Windszus wrote: >> The command for running automated checks against this release >> candidate is: >> $ sh check-release.sh filevault 3.4.8 >> 669663e26d9fe7364a2735bcf237b4719ba1879d > >I am unable to run the tests, or indeed build filevault master. > >With mvn clean verify in the project root I get > >[INFO] --- bnd-indexer-maven-plugin:5.2.0:index (index) @ >org.apache.jackrabbit.vault.target-osgi-environment --- >[ERROR] Failed to determine the artifact URI for artifact >javax.jcr:jcr:jar:2.0 >java.io.FileNotFoundException: Unable to index artifact >javax.jcr:jcr:jar:2.0. The repository local is not known to this resolver > >I am building with > >Apache Maven 3.6.3 (SUSE 3.6.3-2.5) >Maven home: /usr/share/maven >Java version: 11.0.9.1, vendor: Oracle Corporation, runtime: >/usr/lib64/jvm/java-11-openjdk-11 >Default locale: en_US, platform encoding: UTF-8 >OS name: "linux", version: "5.10.4-1-default", arch: "amd64", family: >"unix" > >Not sure if related, but the Maven central metadata does not seem to >include the 2.0 version in its listing > >https://repo.maven.apache.org/maven2/javax/jcr/jcr/maven-metadata.xml > > > javax.jcr > jcr > 1.0 > > > 1.0 > 1.0.1 > > > > >Does anyone else have this problem? > >Thanks, >Robert
RE: [VOTE] Release Jackrabbit FileVault 3.4.8 and FileVault Package Maven Plugin 1.1.6
+1 (non-binding) stefan
[jira] [Commented] (JCRVLT-490) jackrabbit-filevault-package-maven-plugin fails embedding files located on different drives on Windows
[
https://issues.apache.org/jira/browse/JCRVLT-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262833#comment-17262833
]
Stefan Seifert commented on JCRVLT-490:
---
[~kwin] that's definitely the better approach, i validated it locally on
windows, it works.
> jackrabbit-filevault-package-maven-plugin fails embedding files located on
> different drives on Windows
> --
>
> Key: JCRVLT-490
> URL: https://issues.apache.org/jira/browse/JCRVLT-490
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.6
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: package-maven-plugin-1.1.6
>
>
> e.g. the project is on drive {{D:}} and the maven repository on drive {{C:}}
> - the package step then fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
> (default-package) on project io.wcm.samples.complete: Execution
> default-package of goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
> failed: 'other' has different root -> [Help 1]
> {noformat}
> root cause is a method to beautify the filenames for log output introduced in
> JCRVLT-471 - i will prepare a PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
RE: new filevault and filevault-package-maven-plugin release?
i've found a new issue (provided PR): https://issues.apache.org/jira/browse/JCRVLT-490 but besides this, it looks fine! did tests with a couple of projects. stefan >-Original Message- >From: Konrad Windszus >Sent: Friday, January 8, 2021 10:57 AM >To: dev@jackrabbit.apache.org >Subject: Re: new filevault and filevault-package-maven-plugin release? > >Hi Stefan, >I just deployed the most recent snapshots of both projects. Can you try >those out on some bigger projects? >I would like to gather some feedback before starting the release >process >But IMHO there is nothing blocking the release any longer. > >Thanks, >Konrad > > >On 8. Jan 2021, at 09:54, Stefan Seifert <mailto:stefan.seif...@diva-e.com> >wrote: > >hello konrad. > >bringing this topic back - i'm interested in a release of both. any >blockers left? > >https://issues.apache.org/jira/browse/JCRVLT-458 is still open, but it is >an improvement and should not block the release? > >stefan > > > >-Original Message- >From: Konrad Windszus <mailto:konra...@gmx.de> >Sent: Friday, December 4, 2020 11:59 AM >To: mailto:dev@jackrabbit.apache.org >Subject: Re: new filevault and filevault-package-maven-plugin release? > >Hi Stefan, >IIUC all of the issues are only related to the node type validator which >has been introduced in 3.4.8 and indeed suffered from several flaws. >However that validator can be easily disabled >(https://jackrabbit.apache.org/filevault/validation.html#Settings). >The other validators are not affected... Please correct me if I am wrong. > >Still having a fully working node type validator would obviously be nice to >have. There are a few more things I would like to include in the upcoming >release (because even getting the required amount of votes is sometimes >hard in the Jackrabbit project), but since I am the only active committer >on this project this may require few more days. > >Everyone can help though, e.g. by adding a fix >for https://issues.apache.org/jira/browse/JCRVLT-485 or >for https://issues.apache.org/jira/browse/JCRVLT-458. I will go trough the >list of issues targeted for FileVault 3.4.8 and and package-maven-plugin >1.1.6 and move everything out which I consider not crucial... > >Konrad > > > >On 4. Dec 2020, at 11:29, Stefan Seifert <mailto:sseif...@pro-vision.de> >wrote: > >the current released versions filevault-validation and filevault-package- >maven-plugin have some problems when validating local package content. is >it possible to do a release for both of them soon. > >there is a long list of open issues for filevault 3.4.8 [1] and plugin >1.1.16 [2], but i think most of them can be moved to a future version >(release early, release often). > >i'm personally very interested in incorporating the PRs for JCRVLT-480, >JCRVLT-483, JCRVLT-484, JCRVLT-486 in the next release. > >stefan > >[1] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348445 >[2] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348444
[jira] [Updated] (JCRVLT-490) jackrabbit-filevault-package-maven-plugin fails embedding files located on different drives on Windows
[
https://issues.apache.org/jira/browse/JCRVLT-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-490:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/49
> jackrabbit-filevault-package-maven-plugin fails embedding files located on
> different drives on Windows
> --
>
> Key: JCRVLT-490
> URL: https://issues.apache.org/jira/browse/JCRVLT-490
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.6
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: package-maven-plugin-1.1.6
>
>
> e.g. the project is on drive {{D:}} and the maven repository on drive {{C:}}
> - the package step then fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
> (default-package) on project io.wcm.samples.complete: Execution
> default-package of goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
> failed: 'other' has different root -> [Help 1]
> {noformat}
> root cause is a method to beautify the filenames for log output introduced in
> JCRVLT-471 - i will prepare a PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-490) jackrabbit-filevault-package-maven-plugin fails embedding files located on different drives on Windows
Stefan Seifert created JCRVLT-490:
-
Summary: jackrabbit-filevault-package-maven-plugin fails embedding
files located on different drives on Windows
Key: JCRVLT-490
URL: https://issues.apache.org/jira/browse/JCRVLT-490
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.6
Reporter: Stefan Seifert
Fix For: package-maven-plugin-1.1.6
e.g. the project is on drive {{D:}} and the maven repository on drive {{C:}} -
the package step then fails with:
{noformat}
[ERROR] Failed to execute goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
(default-package) on project io.wcm.samples.complete: Execution default-package
of goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.1.5-SNAPSHOT:package
failed: 'other' has different root -> [Help 1]
{noformat}
root cause is a method to beautify the filenames for log output introduced in
JCRVLT-471 - i will prepare a PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
RE: new filevault and filevault-package-maven-plugin release?
hello konrad. bringing this topic back - i'm interested in a release of both. any blockers left? https://issues.apache.org/jira/browse/JCRVLT-458 is still open, but it is an improvement and should not block the release? stefan >-Original Message- >From: Konrad Windszus >Sent: Friday, December 4, 2020 11:59 AM >To: dev@jackrabbit.apache.org >Subject: Re: new filevault and filevault-package-maven-plugin release? > >Hi Stefan, >IIUC all of the issues are only related to the node type validator which >has been introduced in 3.4.8 and indeed suffered from several flaws. >However that validator can be easily disabled >(https://jackrabbit.apache.org/filevault/validation.html#Settings). >The other validators are not affected... Please correct me if I am wrong. > >Still having a fully working node type validator would obviously be nice to >have. There are a few more things I would like to include in the upcoming >release (because even getting the required amount of votes is sometimes >hard in the Jackrabbit project), but since I am the only active committer >on this project this may require few more days. > >Everyone can help though, e.g. by adding a fix >for https://issues.apache.org/jira/browse/JCRVLT-485 or >for https://issues.apache.org/jira/browse/JCRVLT-458. I will go trough the >list of issues targeted for FileVault 3.4.8 and and package-maven-plugin >1.1.6 and move everything out which I consider not crucial... > >Konrad > > > >On 4. Dec 2020, at 11:29, Stefan Seifert <mailto:sseif...@pro-vision.de> >wrote: > >the current released versions filevault-validation and filevault-package- >maven-plugin have some problems when validating local package content. is >it possible to do a release for both of them soon. > >there is a long list of open issues for filevault 3.4.8 [1] and plugin >1.1.16 [2], but i think most of them can be moved to a future version >(release early, release often). > >i'm personally very interested in incorporating the PRs for JCRVLT-480, >JCRVLT-483, JCRVLT-484, JCRVLT-486 in the next release. > >stefan > >[1] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348445 >[2] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348444
adaptTo() Developer Conference 2021
Dear adaptTo() Community, adaptTo() is Europe's leading AEM developer conference. Many great lectures about Adobe Experience Manager (AEM), Apache Sling, Apache Felix, and Apache Jackrabbit Oak. In 2021 we plan a hybrid setup with a digital platform combined with an in-person meeting in Germany. Save the date for next year: 27th - 29th September 2021 Tickets sales start: 1st February 2021 Call for papers: February to April 2021 If you are interested in becoming a sponsor of this year's event, let us know at spon...@adaptto.org. For more information, please visit us at https://adapt.to or share your thoughts via i...@adaptto.org. Have yourself a Merry Christmas and a Happy New Year! Kind regards from the adaptTo() Team, Stefan P.S. All video recordings and slides from 2020 are online: https://adapt.to/2020/schedule
adaptTo() Developer Conference 2021
Dear adaptTo() Community, adaptTo() is Europe's leading AEM developer conference. Many great lectures about Adobe Experience Manager (AEM), Apache Sling, Apache Felix, and Apache Jackrabbit Oak. In 2021 we plan a hybrid setup with a digital platform combined with an in-person meeting in Germany. Save the date for next year: 27th - 29th September 2021 Tickets sales start: 1st February 2021 Call for papers: February to April 2021 If you are interested in becoming a sponsor of this year's event, let us know at spon...@adaptto.org. For more information, please visit us at https://adapt.to or share your thoughts via i...@adaptto.org. Have yourself a Merry Christmas and a Happy New Year! Kind regards from the adaptTo() Team, Stefan P.S. All video recordings and slides from 2020 are online: https://adapt.to/2020/schedule
[jira] [Updated] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-485:
--
Flags: Patch
PR which fixes the problem by checking against a list of special-handling
properties:
https://github.com/apache/jackrabbit-filevault/pull/110
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.4.8
>
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
new filevault and filevault-package-maven-plugin release?
the current released versions filevault-validation and filevault-package-maven-plugin have some problems when validating local package content. is it possible to do a release for both of them soon. there is a long list of open issues for filevault 3.4.8 [1] and plugin 1.1.16 [2], but i think most of them can be moved to a future version (release early, release often). i'm personally very interested in incorporating the PRs for JCRVLT-480, JCRVLT-483, JCRVLT-484, JCRVLT-486 in the next release. stefan [1] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348445 [2] https://issues.apache.org/jira/browse/JCRVLT/fixforversion/12348444
[jira] [Updated] (JCRVLT-486) nodetype validation: Allow to define list of valid namespaces
[
https://issues.apache.org/jira/browse/JCRVLT-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-486:
--
Flags: Patch
patch proposal: https://github.com/apache/jackrabbit-filevault/pull/109
adds a new validation option "validNameSpaces" accepting a string like
{noformat}
refix1=ns-uri1,prefix2=nsuri2,...
{noformat}
> nodetype validation: Allow to define list of valid namespaces
> -
>
> Key: JCRVLT-486
> URL: https://issues.apache.org/jira/browse/JCRVLT-486
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: Stefan Seifert
>Priority: Major
>
> content stored in the packages may contain arbitrary namespaces not contained
> in any of the prepackaged CND node type definitions used for validation.
> after checking that the namespace is correct it should be possible to
> configure this namespace(s) for the package to be valid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-486) nodetype validation: Allow to define list of valid namespaces
Stefan Seifert created JCRVLT-486: - Summary: nodetype validation: Allow to define list of valid namespaces Key: JCRVLT-486 URL: https://issues.apache.org/jira/browse/JCRVLT-486 Project: Jackrabbit FileVault Issue Type: New Feature Components: vlt Reporter: Stefan Seifert content stored in the packages may contain arbitrary namespaces not contained in any of the prepackaged CND node type definitions used for validation. after checking that the namespace is correct it should be possible to configure this namespace(s) for the package to be valid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243058#comment-17243058
]
Stefan Seifert commented on JCRVLT-485:
---
i tried to create a unit test to reproduce the problem - but the problem does
not occur in the test. i'm not sure if the test setup is correct - draft PR:
https://github.com/apache/jackrabbit-filevault/pull/108
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.4.8
>
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242289#comment-17242289
]
Stefan Seifert commented on JCRVLT-485:
---
bq. an you confirm that those are there after an import of the attached package?
indeed they are
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.4.8
>
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242289#comment-17242289
]
Stefan Seifert edited comment on JCRVLT-485 at 12/2/20, 11:53 AM:
--
bq. can you confirm that those are there after an import of the attached
package?
indeed they are
was (Author: sseif...@pro-vision.de):
bq. an you confirm that those are there after an import of the attached package?
indeed they are
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.4.8
>
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242224#comment-17242224
]
Stefan Seifert commented on JCRVLT-485:
---
the CND for mix versionable:
{noformat}
[mix:versionable] > mix:referenceable, mix:simpleVersionable
mixin
- jcr:versionHistory (reference) mandatory protected ignore <
'nt:versionHistory'
- jcr:baseVersion (reference) mandatory protected ignore < 'nt:version'
- jcr:predecessors (reference) mandatory protected multiple ignore <
'nt:version'
- jcr:mergeFailed (reference) protected multiple abort < 'nt:version'
- jcr:activity (reference) protected < 'nt:activity'
- jcr:configuration (reference) protected ignore < 'nt:configuration'
{noformat}
the affected property are set to "protected", "mandatory" and also to "ignore".
not sure what the latter means, but probable we should "ignore" the validation
for those properties as well?
[~kwin] WDYT?
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
>Reporter: Stefan Seifert
>Priority: Major
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
Stefan Seifert created JCRVLT-485:
-
Summary: Validation fails for nodetypes extending mix:versionable
Key: JCRVLT-485
URL: https://issues.apache.org/jira/browse/JCRVLT-485
Project: Jackrabbit FileVault
Issue Type: Bug
Components: vlt
Affects Versions: 3.4.8
Reporter: Stefan Seifert
when validation a content package containing data with a node type extending
mix:versionable (and the protected properties are stripped out of the local
content) validation failes with:
{noformat}
ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
/var/workflow/models/dam/dam_update_asset1"
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
/var/workflow/models/dam/dam_update_asset1"
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
/var/workflow/models/dam/dam_update_asset1"
{noformat}
sample project to reproduce the problem:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-484) Filter settings should ignore whitespaces when splitting comma-separated strings
[
https://issues.apache.org/jira/browse/JCRVLT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-484:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault/pull/107
> Filter settings should ignore whitespaces when splitting comma-separated
> strings
>
>
> Key: JCRVLT-484
> URL: https://issues.apache.org/jira/browse/JCRVLT-484
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
>
> when parsing a filter definition like this:
> {code:xml}
>
>
>
>
> /conf/global/settings/workflow/models/dam,
> /var/workflow/models/dam
>
>
>
>
> {code}
> the first entry is interpreted correctly (trimmed by maven), but the second
> not, whitspaces are added to the path. whitespaces around the commas should
> be trimmed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-484) Filter settings should ignore whitespaces when splitting comma-separated strings
Stefan Seifert created JCRVLT-484:
-
Summary: Filter settings should ignore whitespaces when splitting
comma-separated strings
Key: JCRVLT-484
URL: https://issues.apache.org/jira/browse/JCRVLT-484
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: vlt
Affects Versions: 3.4.8
Reporter: Stefan Seifert
when parsing a filter definition like this:
{code:xml}
/conf/global/settings/workflow/models/dam,
/var/workflow/models/dam
{code}
the first entry is interpreted correctly (trimmed by maven), but the second
not, whitspaces are added to the path. whitespaces around the commas should be
trimmed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-483) Package thumbnail image is copied twice (and produced warnings) if placed in META-INF/vault/definition folder
[
https://issues.apache.org/jira/browse/JCRVLT-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-483:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/47
> Package thumbnail image is copied twice (and produced warnings) if placed in
> META-INF/vault/definition folder
> -
>
> Key: JCRVLT-483
> URL: https://issues.apache.org/jira/browse/JCRVLT-483
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: package-maven-plugin-1.1.6
> Reporter: Stefan Seifert
>Priority: Minor
>
> scenario:
> * content package project with a custom thumbnail image stored in the source
> at {{META-INF/vault/definition/thumbnail.png}}
> * the plugin config contains a config parameter
> {code:xml}
> src/main/content/META-INF/vault/definition/thumbnail.png
> {code}
> this produces a warning in the package goal like:
> {noformat}
> [INFO] Packaging content from
> C:\temp\mysite\ui.content\src\main\content\jcr_root
> [WARNING] Found duplicate file 'META-INF\vault\definition\thumbnail.png' from
> sources
> 'C:\temp\mysite\ui.content\src\main\content\META-INF\vault\definition\thumbnail.png'
> and
> 'C:\temp\mysite\ui.content\target\vault-work\META-INF\vault\definition\thumbnail.png'.
> {noformat}
> this does not happen when the thumbnail image is copied from somewhere else,
> but it is convenient to put it rightaway in the correct folder of the source
> project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-483) Package thumbnail image is copied twice (and produced warnings) if placed in META-INF/vault/definition folder
Stefan Seifert created JCRVLT-483:
-
Summary: Package thumbnail image is copied twice (and produced
warnings) if placed in META-INF/vault/definition folder
Key: JCRVLT-483
URL: https://issues.apache.org/jira/browse/JCRVLT-483
Project: Jackrabbit FileVault
Issue Type: Bug
Components: vlt
Affects Versions: package-maven-plugin-1.1.6
Reporter: Stefan Seifert
scenario:
* content package project with a custom thumbnail image stored in the source at
{{META-INF/vault/definition/thumbnail.png}}
* the plugin config contains a config parameter
{code:xml}
src/main/content/META-INF/vault/definition/thumbnail.png
{code}
this produces a warning in the package goal like:
{noformat}
[INFO] Packaging content from
C:\temp\mysite\ui.content\src\main\content\jcr_root
[WARNING] Found duplicate file 'META-INF\vault\definition\thumbnail.png' from
sources
'C:\temp\mysite\ui.content\src\main\content\META-INF\vault\definition\thumbnail.png'
and
'C:\temp\mysite\ui.content\target\vault-work\META-INF\vault\definition\thumbnail.png'.
{noformat}
this does not happen when the thumbnail image is copied from somewhere else,
but it is convenient to put it rightaway in the correct folder of the source
project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-482) ArrayIndexOutOfBoundsException when validating multivalue property with empty value array
Stefan Seifert created JCRVLT-482:
-
Summary: ArrayIndexOutOfBoundsException when validating multivalue
property with empty value array
Key: JCRVLT-482
URL: https://issues.apache.org/jira/browse/JCRVLT-482
Project: Jackrabbit FileVault
Issue Type: Bug
Components: vlt
Affects Versions: 3.4.8
Reporter: Stefan Seifert
when validating a docview property with an empty value array, e.g.
{code:xml}
{code}
validation fails with an exception
{noformat}
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.jackrabbit.vault.validation.spi.impl.nodetype.JcrNodeTypeMetaDataImpl.addProperty
(JcrNodeTypeMetaDataImpl.java:537)
at
org.apache.jackrabbit.vault.validation.spi.impl.nodetype.NodeTypeValidator.addProperty
(NodeTypeValidator.java:148)
at
org.apache.jackrabbit.vault.validation.spi.impl.nodetype.NodeTypeValidator.validate
(NodeTypeValidator.java:128)
at
org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.startElement
(DocumentViewXmlContentHandler.java:199)
...
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-482) ArrayIndexOutOfBoundsException when validating multivalue property with empty value array
[
https://issues.apache.org/jira/browse/JCRVLT-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-482:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault/pull/106
> ArrayIndexOutOfBoundsException when validating multivalue property with empty
> value array
> -
>
> Key: JCRVLT-482
> URL: https://issues.apache.org/jira/browse/JCRVLT-482
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
> Reporter: Stefan Seifert
>Priority: Major
>
> when validating a docview property with an empty value array, e.g.
> {code:xml}
> cq:tags="[]"
> jcr:primaryType="cq:PageContent"/>
> {code}
> validation fails with an exception
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.jackrabbit.vault.validation.spi.impl.nodetype.JcrNodeTypeMetaDataImpl.addProperty
> (JcrNodeTypeMetaDataImpl.java:537)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.nodetype.NodeTypeValidator.addProperty
> (NodeTypeValidator.java:148)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.nodetype.NodeTypeValidator.validate
> (NodeTypeValidator.java:128)
> at
> org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.startElement
> (DocumentViewXmlContentHandler.java:199)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-480) NPE when validating not allowed properties
[ https://issues.apache.org/jira/browse/JCRVLT-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-480: -- Flags: Patch PR: https://github.com/apache/jackrabbit-filevault/pull/105 please double-check if i got the message text for the two cases correct. > NPE when validating not allowed properties > -- > > Key: JCRVLT-480 > URL: https://issues.apache.org/jira/browse/JCRVLT-480 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.4.8 > Reporter: Stefan Seifert >Priority: Major > > in a special code path part of the validation introduced with JCRVTL-462 a > message "null" is formatted leading to a NPE - the message text is missing in > the constant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCRVLT-480) NPE when validating not allowed properties
Stefan Seifert created JCRVLT-480: - Summary: NPE when validating not allowed properties Key: JCRVLT-480 URL: https://issues.apache.org/jira/browse/JCRVLT-480 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Affects Versions: 3.4.8 Reporter: Stefan Seifert in a special code path part of the validation introduced with JCRVTL-462 a message "null" is formatted leading to a NPE - the message text is missing in the constant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-479) jackrabbit-nodetypes validator: validation fails "overeager" for autocreated properties
[
https://issues.apache.org/jira/browse/JCRVLT-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239378#comment-17239378
]
Stefan Seifert commented on JCRVLT-479:
---
so probably we should just remove the validation for autocreated properties?
autocreated is important when creating a new node, but no longer relevant when
validating it after it was created?
i've created a PR doing this:
https://github.com/apache/jackrabbit-filevault/pull/104 (i'm not sure if this
is everything that is required)
> jackrabbit-nodetypes validator: validation fails "overeager" for autocreated
> properties
> ---
>
> Key: JCRVLT-479
> URL: https://issues.apache.org/jira/browse/JCRVLT-479
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.4.6
>Reporter: Stefan Seifert
>Priority: Major
>
> having a property node type definition defined for validation (e.g. from
> [https://github.com/Netcentric/aem-nodetypes]) may lead to problems when the
> node type definition contains properties defined as autocreated.
> example:
> {noformat}
> [cq:Tag] > mix:title, nt:hierarchyNode
> orderable
> - * (undefined) multiple
> - * (undefined)
> - sling:resourceType (string) = 'cq/tagging/components/tag' mandatory
> autocreated
> + * (nt:base) = cq:Tag version
> {noformat}
> the problem is that a package exported from the repository usually contains
> this property and then the validation fails (although the property has
> exactly the value given as default value here). leading to a failed build
> with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
> 'sling:resourceType' [String] is not allowed in node with potential default
> types [cq:Tag]: Property is auto-created and can not be manually added",
> filePath=jcr_root\content\_cq_tags\sample\.content.xml,
> nodePath=/content/cq:tags/sample, line=6, column=52
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> the code currently has a hardcoded list of properties to ignore this behavior
> ({{jcr:primaryType}}, {{jcr:mixingTypes}}). but this does not help for other
> properties. i'm wondering if this validation is really helpful or should be
> removed or disabled? alternatively the list of allowed protected properties
> could be made configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-479) jackrabbit-nodetypes validator: validation fails "overeager" for protected properties
[
https://issues.apache.org/jira/browse/JCRVLT-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-479:
--
Summary: jackrabbit-nodetypes validator: validation fails "overeager" for
protected properties (was: jackrabbit-nodetypes validator: validation fails
"overeager" for protected node types)
> jackrabbit-nodetypes validator: validation fails "overeager" for protected
> properties
> -
>
> Key: JCRVLT-479
> URL: https://issues.apache.org/jira/browse/JCRVLT-479
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.4.6
>Reporter: Stefan Seifert
>Priority: Major
>
> having a property node type definition defined for validation (e.g. from
> [https://github.com/Netcentric/aem-nodetypes]) may lead to problems when the
> node type definition contains properties defined as autocreated.
> example:
> {noformat}
> [cq:Tag] > mix:title, nt:hierarchyNode
> orderable
> - * (undefined) multiple
> - * (undefined)
> - sling:resourceType (string) = 'cq/tagging/components/tag' mandatory
> autocreated
> + * (nt:base) = cq:Tag version
> {noformat}
> the problem is that a package exported from the repository usually contains
> this property and then the validation fails (although the property has
> exactly the value given as default value here). leading to a failed build
> with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
> 'sling:resourceType' [String] is not allowed in node with potential default
> types [cq:Tag]: Property is auto-created and can not be manually added",
> filePath=jcr_root\content\_cq_tags\sample\.content.xml,
> nodePath=/content/cq:tags/sample, line=6, column=52
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> the code currently has a hardcoded list of properties to ignore this behavior
> ({{jcr:primaryType}}, {{jcr:mixingTypes}}). but this does not help for other
> properties. i'm wondering if this validation is really helpful or should be
> removed or disabled? alternatively the list of allowed protected properties
> could be made configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-479) jackrabbit-nodetypes validator: validation fails "overeager" for protected node types
Stefan Seifert created JCRVLT-479:
-
Summary: jackrabbit-nodetypes validator: validation fails
"overeager" for protected node types
Key: JCRVLT-479
URL: https://issues.apache.org/jira/browse/JCRVLT-479
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: vlt
Affects Versions: 3.4.6
Reporter: Stefan Seifert
having a property node type definition defined for validation (e.g. from
[https://github.com/Netcentric/aem-nodetypes]) may lead to problems when the
node type definition contains properties defined as autocreated.
example:
{noformat}
[cq:Tag] > mix:title, nt:hierarchyNode
orderable
- * (undefined) multiple
- * (undefined)
- sling:resourceType (string) = 'cq/tagging/components/tag' mandatory
autocreated
+ * (nt:base) = cq:Tag version
{noformat}
the problem is that a package exported from the repository usually contains
this property and then the validation fails (although the property has exactly
the value given as default value here). leading to a failed build with:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
'sling:resourceType' [String] is not allowed in node with potential default
types [cq:Tag]: Property is auto-created and can not be manually added",
filePath=jcr_root\content\_cq_tags\sample\.content.xml,
nodePath=/content/cq:tags/sample, line=6, column=52
{noformat}
sample project to reproduce the problem:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
the code currently has a hardcoded list of properties to ignore this behavior
({{jcr:primaryType}}, {{jcr:mixingTypes}}). but this does not help for other
properties. i'm wondering if this validation is really helpful or should be
removed or disabled? alternatively the list of allowed protected properties
could be made configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-477) package maven plugin filtering complains about platform encoding although project.build.sourceEncoding is set
[
https://issues.apache.org/jira/browse/JCRVLT-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-477:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/45
it seems the resourceEncoding parameter introduced in JCRVLT-389 was not used
at all. the PR fixes the problem for me and resource filtering still working as
expected.
> package maven plugin filtering complains about platform encoding although
> project.build.sourceEncoding is set
> -
>
> Key: JCRVLT-477
> URL: https://issues.apache.org/jira/browse/JCRVLT-477
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Priority: Major
>
> when building this content package project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/ui.apps
> this warning is reported:
> {noformat}
> [INFO] Apply filtering to FileSet below
> D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes\apps\filevaultsample\clientlibs
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Using 'null' encoding to copy filtered properties files.
> [INFO] Copying 20 resources to
> D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\filteredFiles\jcr_root\apps\filevaultsample\clientlibs
> [INFO] Apply filtering to FileSet below
> D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes\apps\filevaultsample\core
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> {noformat}
> it complains twice about the missing encoding configuration.
> following the documentation from
> http://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#resourceEncoding
> the default for the encoding is the maven property
> {{project.build.sourceEncoding}}
> which is configured in one of the parent POMs of this project (visible e.g.
> when using {{help:effective-pom}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JCRVLT-478) package maven plugin reports warning when classifier option is not used
[
https://issues.apache.org/jira/browse/JCRVLT-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved JCRVLT-478.
---
Fix Version/s: package-maven-plugin-1.1.6
Resolution: Fixed
merged, thanks:
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/0352e3144fe3d5afb309571bfbc9ccd6b15d73cb
> package maven plugin reports warning when classifier option is not used
> ---
>
> Key: JCRVLT-478
> URL: https://issues.apache.org/jira/browse/JCRVLT-478
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Priority: Trivial
> Fix For: package-maven-plugin-1.1.6
>
>
> since introduction of JCRVLT-434 each package builds logs a warning like this:
> {noformat}
> [INFO] Packaging content from
> D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes
> [WARNING] Using regular embedded files map as classifier specific one does
> not exist!
> {noformat}
> sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/ui.apps
> this warning makes no sense as this is an optional feature and everything is
> fine without using it. in my pov it should be switched to a DEBUG message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-478) package maven plugin reports warning when classifier option is not used
[
https://issues.apache.org/jira/browse/JCRVLT-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-478:
--
Flags: Patch
PR: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/44
> package maven plugin reports warning when classifier option is not used
> ---
>
> Key: JCRVLT-478
> URL: https://issues.apache.org/jira/browse/JCRVLT-478
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Priority: Trivial
>
> since introduction of JCRVLT-434 each package builds logs a warning like this:
> {noformat}
> [INFO] Packaging content from
> D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes
> [WARNING] Using regular embedded files map as classifier specific one does
> not exist!
> {noformat}
> sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/ui.apps
> this warning makes no sense as this is an optional feature and everything is
> fine without using it. in my pov it should be switched to a DEBUG message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-478) package maven plugin reports warning when classifier option is not used
Stefan Seifert created JCRVLT-478:
-
Summary: package maven plugin reports warning when classifier
option is not used
Key: JCRVLT-478
URL: https://issues.apache.org/jira/browse/JCRVLT-478
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.4
Reporter: Stefan Seifert
since introduction of JCRVLT-434 each package builds logs a warning like this:
{noformat}
[INFO] Packaging content from
D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes
[WARNING] Using regular embedded files map as classifier specific one does not
exist!
{noformat}
sample project:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/ui.apps
this warning makes no sense as this is an optional feature and everything is
fine without using it. in my pov it should be switched to a DEBUG message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-477) package maven plugin filtering complains about platform encoding although project.build.sourceEncoding is set
Stefan Seifert created JCRVLT-477:
-
Summary: package maven plugin filtering complains about platform
encoding although project.build.sourceEncoding is set
Key: JCRVLT-477
URL: https://issues.apache.org/jira/browse/JCRVLT-477
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.4
Reporter: Stefan Seifert
when building this content package project:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/ui.apps
this warning is reported:
{noformat}
[INFO] Apply filtering to FileSet below
D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes\apps\filevaultsample\clientlibs
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Using 'null' encoding to copy filtered properties files.
[INFO] Copying 20 resources to
D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\filteredFiles\jcr_root\apps\filevaultsample\clientlibs
[INFO] Apply filtering to FileSet below
D:\Develop\github\filevault-package-maven-plugin-validation-issues\content-packages\ui.apps\target\classes\apps\filevaultsample\core
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
{noformat}
it complains twice about the missing encoding configuration.
following the documentation from
http://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#resourceEncoding
the default for the encoding is the maven property
{{project.build.sourceEncoding}}
which is configured in one of the parent POMs of this project (visible e.g.
when using {{help:effective-pom}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-463) jackrabbit-nodetypes: Mandatory child node missing: jcr:content [nt:base]
[
https://issues.apache.org/jira/browse/JCRVLT-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222155#comment-17222155
]
Stefan Seifert commented on JCRVLT-463:
---
lgtm with plugin 1.1.5-SNAPSHOT - thanks
> jackrabbit-nodetypes: Mandatory child node missing: jcr:content [nt:base]
> -
>
> Key: JCRVLT-463
> URL: https://issues.apache.org/jira/browse/JCRVLT-463
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.6
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.8
>
>
> the node type validator complains fails with this error message:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node
> missing: jcr:content [nt:base]",
> filePath=jcr_root\conf\filevaultsample\settings\wcm\templates\contentpage\thumbnail.png.dir\.content.xml,
>
> nodePath=/conf/filevaultsample/settings/wcm/templates/contentpage/thumbnail.png,
> line=7, column=12
> {noformat}
> when a content package is downloaded from AEM that contains editable template
> definitions with a thumbnail image. but the content structure looks ok, so i
> assume this validation error is a bug.
> it can be reproduced with this sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-462) Nodetype validator complains about root node
[
https://issues.apache.org/jira/browse/JCRVLT-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222152#comment-17222152
]
Stefan Seifert commented on JCRVLT-462:
---
lgtm with plugin 1.1.5-SNAPSHOT - thanks
> Nodetype validator complains about root node
>
>
> Key: JCRVLT-462
> URL: https://issues.apache.org/jira/browse/JCRVLT-462
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.6, package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.8
>
>
> if a content package is downloaded via CRX package manager it usually also
> contains intermediate note definitions up to the root node in the
> {{jcr_root}} folder.
> the nodetype validator added recently complains about this root node
> definition which is included by default:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Node
> '{http://www.jcp.org/jcr/1.0}root [rep:root (rep:AccessControllable,
> rep:RepoAccessControllable)]' is not allowed as child of not contained node
> with potential default types '[nt:folder]': Could not find matching child
> node definition in parent's node type", filePath=jcr_root\.content.xml,
> nodePath=/, line=6, column=33
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node
> missing: jcr:system [rep:system]", filePath=jcr_root\.content.xml,
> nodePath=/, line=6, column=33
> {noformat}
> as a workaround i could remove the {{.content.xml}} file from the
> {{jcr_root}} folder, but i prefer to keep exactly the content that is
> contained in the content package.
> with this AEM sample project it is possible to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JCRVLT-464) jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not intended
[
https://issues.apache.org/jira/browse/JCRVLT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved JCRVLT-464.
---
Resolution: Won't Fix
ok, then i will close this issue
> jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not
> intended
>
>
> Key: JCRVLT-464
> URL: https://issues.apache.org/jira/browse/JCRVLT-464
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> the latest version of {{jackrabbit-filevault-package-maven-plugin}} is
> detected by {{versions-maven-plugin}} to required Maven 3.6.1:
> {noformat}
> [INFO] --- versions-maven-plugin:2.8.1:display-plugin-updates (default-cli) @
> io.wcm.maven.aem-global-parent ---
> [INFO]
> [INFO] The following plugin updates are available:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.2
> [INFO]
> [INFO] All plugins have a version specified.
> [INFO]
> [INFO] Project inherits minimum Maven version as: 3.6.0
> [INFO] Plugins require minimum Maven version of: 3.6.0
> [INFO]
> [INFO] No plugins require a newer version of Maven than specified by the pom.
> [INFO]
> [INFO] Require Maven 3.6.1 to use the following plugin updates:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.4
> {noformat}
> but this does not seem to be intended as the pom itself defines Maven 3.3.9
> as prerequisite:
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/725276dbb3f51b8845aa80eac4beeb2bcdd1b127/pom.xml#L42
> with version 1.1.4 the parent pom was switched to
> {{org.apache.jackrabbit.vault:parent}} 3.4.6, and this defines
> {{maven.version}} to 3.6.1 and some additional enforcer rules. it seems the
> {{versions-maven-plugins}} gets this version information from the enforcer
> rules and expects 3.6.1 as minimum required version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-464) jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not intended
[
https://issues.apache.org/jira/browse/JCRVLT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175816#comment-17175816
]
Stefan Seifert commented on JCRVLT-464:
---
the question is: should we do anything in filevault-package-maven-plugin so it
does not report "false" min maven version requirements when using
{{versions:display-plugin-updates}} (which is suppose is used by a lot of
users). e.g. removing the vlt parent dependency from the plugin, or not
defining the min maven version in the vtl parent.
> jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not
> intended
>
>
> Key: JCRVLT-464
> URL: https://issues.apache.org/jira/browse/JCRVLT-464
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> the latest version of {{jackrabbit-filevault-package-maven-plugin}} is
> detected by {{versions-maven-plugin}} to required Maven 3.6.1:
> {noformat}
> [INFO] --- versions-maven-plugin:2.8.1:display-plugin-updates (default-cli) @
> io.wcm.maven.aem-global-parent ---
> [INFO]
> [INFO] The following plugin updates are available:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.2
> [INFO]
> [INFO] All plugins have a version specified.
> [INFO]
> [INFO] Project inherits minimum Maven version as: 3.6.0
> [INFO] Plugins require minimum Maven version of: 3.6.0
> [INFO]
> [INFO] No plugins require a newer version of Maven than specified by the pom.
> [INFO]
> [INFO] Require Maven 3.6.1 to use the following plugin updates:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.4
> {noformat}
> but this does not seem to be intended as the pom itself defines Maven 3.3.9
> as prerequisite:
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/725276dbb3f51b8845aa80eac4beeb2bcdd1b127/pom.xml#L42
> with version 1.1.4 the parent pom was switched to
> {{org.apache.jackrabbit.vault:parent}} 3.4.6, and this defines
> {{maven.version}} to 3.6.1 and some additional enforcer rules. it seems the
> {{versions-maven-plugins}} gets this version information from the enforcer
> rules and expects 3.6.1 as minimum required version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-464) jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not intended
[
https://issues.apache.org/jira/browse/JCRVLT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175813#comment-17175813
]
Stefan Seifert commented on JCRVLT-464:
---
i suppose the intention of the logic in the versions-maven-plugin besides
simple inheritance is to allow to step in additional enforcer rules defined in
parent poms as well. but how it is implemented the highest required maven
version wins wherever it is defined in the parent hierarchy chain.
but it is debatable if the logic is really wrong. after all if the parent has
e.g. a couple of plugins defined that required maven 3.6.1 these plugins also
get active in the child pom, independently of what min maven version it itself
defines. i would tend to accept that the current logic of versions-maven-plugin
is on the "safe side" and is unlikely to be changed.
leaving the question what to do with this issue - should the min version of
maven 3.6.1 be accepted (should not be a problem for developers - but CI/CD
systems might be slower in picking up new version - adobe cloud manager is
still in 3.6.0 currently...)
> jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not
> intended
>
>
> Key: JCRVLT-464
> URL: https://issues.apache.org/jira/browse/JCRVLT-464
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> the latest version of {{jackrabbit-filevault-package-maven-plugin}} is
> detected by {{versions-maven-plugin}} to required Maven 3.6.1:
> {noformat}
> [INFO] --- versions-maven-plugin:2.8.1:display-plugin-updates (default-cli) @
> io.wcm.maven.aem-global-parent ---
> [INFO]
> [INFO] The following plugin updates are available:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.2
> [INFO]
> [INFO] All plugins have a version specified.
> [INFO]
> [INFO] Project inherits minimum Maven version as: 3.6.0
> [INFO] Plugins require minimum Maven version of: 3.6.0
> [INFO]
> [INFO] No plugins require a newer version of Maven than specified by the pom.
> [INFO]
> [INFO] Require Maven 3.6.1 to use the following plugin updates:
> [INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.4
> {noformat}
> but this does not seem to be intended as the pom itself defines Maven 3.3.9
> as prerequisite:
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/725276dbb3f51b8845aa80eac4beeb2bcdd1b127/pom.xml#L42
> with version 1.1.4 the parent pom was switched to
> {{org.apache.jackrabbit.vault:parent}} 3.4.6, and this defines
> {{maven.version}} to 3.6.1 and some additional enforcer rules. it seems the
> {{versions-maven-plugins}} gets this version information from the enforcer
> rules and expects 3.6.1 as minimum required version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-464) jackrabbit-filevault-package-maven-plugin requires Maven 3.6.1 although not intended
Stefan Seifert created JCRVLT-464:
-
Summary: jackrabbit-filevault-package-maven-plugin requires Maven
3.6.1 although not intended
Key: JCRVLT-464
URL: https://issues.apache.org/jira/browse/JCRVLT-464
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.4
Reporter: Stefan Seifert
the latest version of {{jackrabbit-filevault-package-maven-plugin}} is detected
by {{versions-maven-plugin}} to required Maven 3.6.1:
{noformat}
[INFO] --- versions-maven-plugin:2.8.1:display-plugin-updates (default-cli) @
io.wcm.maven.aem-global-parent ---
[INFO]
[INFO] The following plugin updates are available:
[INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.2
[INFO]
[INFO] All plugins have a version specified.
[INFO]
[INFO] Project inherits minimum Maven version as: 3.6.0
[INFO] Plugins require minimum Maven version of: 3.6.0
[INFO]
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO]
[INFO] Require Maven 3.6.1 to use the following plugin updates:
[INFO] org.apache.jackrabbit:filevault-package-maven-plugin 1.1.0 -> 1.1.4
{noformat}
but this does not seem to be intended as the pom itself defines Maven 3.3.9 as
prerequisite:
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/725276dbb3f51b8845aa80eac4beeb2bcdd1b127/pom.xml#L42
with version 1.1.4 the parent pom was switched to
{{org.apache.jackrabbit.vault:parent}} 3.4.6, and this defines
{{maven.version}} to 3.6.1 and some additional enforcer rules. it seems the
{{versions-maven-plugins}} gets this version information from the enforcer
rules and expects 3.6.1 as minimum required version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-461) jackrabbit-nodetypes: Mandatory property ''{http://www.jcp.org/jcr/1.0}data' missing in node with types [oak:Resource]
[
https://issues.apache.org/jira/browse/JCRVLT-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175512#comment-17175512
]
Stefan Seifert commented on JCRVLT-461:
---
JCRVLT-463 is probably the same problem, although the error message is
different.
> jackrabbit-nodetypes: Mandatory property ''{http://www.jcp.org/jcr/1.0}data'
> missing in node with types [oak:Resource]
> --
>
> Key: JCRVLT-461
> URL: https://issues.apache.org/jira/browse/JCRVLT-461
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.8
>
>
> This is due to the fact that currently only {{jcr:data}} property attributes
> below {{nt:resource}} types are ignored (but not below {{oak:Resource}}).
> In general an improved
> https://jackrabbit.apache.org/filevault/vaultfs.html#Extended_File_aggregates
> and https://jackrabbit.apache.org/filevault/vaultfs.html#Resource_Nodes
> handling should be implemented which
> # detects {{jcr:data}} properties provided by binary files
> # will defer checking for mandatory missing properties until the parent node
> is fully processed (i.e. attributes by sibling files are processed)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-463) jackrabbit-nodetypes: Mandatory child node missing: jcr:content [nt:base]
Stefan Seifert created JCRVLT-463:
-
Summary: jackrabbit-nodetypes: Mandatory child node missing:
jcr:content [nt:base]
Key: JCRVLT-463
URL: https://issues.apache.org/jira/browse/JCRVLT-463
Project: Jackrabbit FileVault
Issue Type: Bug
Components: vlt
Affects Versions: package-maven-plugin-1.1.4, 3.4.6
Reporter: Stefan Seifert
the node type validator complains fails with this error message:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node
missing: jcr:content [nt:base]",
filePath=jcr_root\conf\filevaultsample\settings\wcm\templates\contentpage\thumbnail.png.dir\.content.xml,
nodePath=/conf/filevaultsample/settings/wcm/templates/contentpage/thumbnail.png,
line=7, column=12
{noformat}
when a content package is downloaded from AEM that contains editable template
definitions with a thumbnail image. but the content structure looks ok, so i
assume this validation error is a bug.
it can be reproduced with this sample project:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-462) Nodetype validator complains about root node
[
https://issues.apache.org/jira/browse/JCRVLT-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-462:
--
Component/s: vlt
> Nodetype validator complains about root node
>
>
> Key: JCRVLT-462
> URL: https://issues.apache.org/jira/browse/JCRVLT-462
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.6, package-maven-plugin-1.1.4
> Reporter: Stefan Seifert
>Priority: Major
>
> if a content package is downloaded via CRX package manager it usually also
> contains intermediate note definitions up to the root node in the
> {{jcr_root}} folder.
> the nodetype validator added recently complains about this root node
> definition which is included by default:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Node
> '{http://www.jcp.org/jcr/1.0}root [rep:root (rep:AccessControllable,
> rep:RepoAccessControllable)]' is not allowed as child of not contained node
> with potential default types '[nt:folder]': Could not find matching child
> node definition in parent's node type", filePath=jcr_root\.content.xml,
> nodePath=/, line=6, column=33
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node
> missing: jcr:system [rep:system]", filePath=jcr_root\.content.xml,
> nodePath=/, line=6, column=33
> {noformat}
> as a workaround i could remove the {{.content.xml}} file from the
> {{jcr_root}} folder, but i prefer to keep exactly the content that is
> contained in the content package.
> with this AEM sample project it is possible to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-461) jackrabbit-nodetypes: Mandatory property ''{http://www.jcp.org/jcr/1.0}data' missing in node with types [oak:Resource]
[
https://issues.apache.org/jira/browse/JCRVLT-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175500#comment-17175500
]
Stefan Seifert commented on JCRVLT-461:
---
i stumbled about the same problem - it can be reproduced with this (AEM) test
project:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> jackrabbit-nodetypes: Mandatory property ''{http://www.jcp.org/jcr/1.0}data'
> missing in node with types [oak:Resource]
> --
>
> Key: JCRVLT-461
> URL: https://issues.apache.org/jira/browse/JCRVLT-461
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.8
>
>
> This is due to the fact that currently only {{jcr:data}} property attributes
> below {{nt:resource}} types are ignored (but not below {{oak:Resource}}).
> In general an improved
> https://jackrabbit.apache.org/filevault/vaultfs.html#Extended_File_aggregates
> and https://jackrabbit.apache.org/filevault/vaultfs.html#Resource_Nodes
> handling should be implemented which
> # detects {{jcr:data}} properties provided by binary files
> # will defer checking for mandatory missing properties until the parent node
> is fully processed (i.e. attributes by sibling files are processed)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-462) Nodetype validator complains about root node
Stefan Seifert created JCRVLT-462:
-
Summary: Nodetype validator complains about root node
Key: JCRVLT-462
URL: https://issues.apache.org/jira/browse/JCRVLT-462
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: package-maven-plugin-1.1.4, 3.4.6
Reporter: Stefan Seifert
if a content package is downloaded via CRX package manager it usually also
contains intermediate note definitions up to the root node in the {{jcr_root}}
folder.
the nodetype validator added recently complains about this root node definition
which is included by default:
{noformat}
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Node
'{http://www.jcp.org/jcr/1.0}root [rep:root (rep:AccessControllable,
rep:RepoAccessControllable)]' is not allowed as child of not contained node
with potential default types '[nt:folder]': Could not find matching child node
definition in parent's node type", filePath=jcr_root\.content.xml, nodePath=/,
line=6, column=33
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node
missing: jcr:system [rep:system]", filePath=jcr_root\.content.xml, nodePath=/,
line=6, column=33
{noformat}
as a workaround i could remove the {{.content.xml}} file from the {{jcr_root}}
folder, but i prefer to keep exactly the content that is contained in the
content package.
with this AEM sample project it is possible to reproduce the problem:
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/conf-content
https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
adaptTo() 2020 - Agenda and speakers
Hi everyone, we are happy to present to you the official adaptTo() 2020 agenda, packed with more talks than ever: https://adapt.to/schedule This year's speakers are leading developers and architects in their field: https://adapt.to/speaker Early bird tickets are still available! Grab your ticket at https://adapt.to/tickets We are looking forward to welcoming you in our virtual online conference, there will be lots of possibilities to get in touch with the speakers and other participants. Kind regards on behalf of the adaptTo() Team Stefan
adaptTo() 2020 - Agenda and speakers
Hi everyone, we are happy to present to you the official adaptTo() 2020 agenda, packed with more talks than ever: https://adapt.to/schedule This year's speakers are leading developers and architects in their field: https://adapt.to/speaker Early bird tickets are still available! Grab your ticket at https://adapt.to/tickets We are looking forward to welcoming you in our virtual online conference, there will be lots of possibilities to get in touch with the speakers and other participants. Kind regards on behalf of the adaptTo() Team Stefan
adaptTo() 2020 Conference goes virtual!
Dear adaptTo() Community, This year's adaptTo() conference in September 2020 will be a *virtual online conference*, and it will be much more than just streaming videos. Look forward for over 35 talks, workshops, panel discussions, social interaction and networking sessions. The agenda will be published in July. We've restarted ticket sales with a completely new pricing, early bird tickets are available till end of July https://adapt.to/tickets For more information please visit us at https://adapt.to or share your thoughts via i...@adaptto.org or #adaptto or at https://adapt.to/linkedin Kind regards from the adaptTo() Team, Stefan
adaptTo() 2020 Conference goes virtual!
Dear adaptTo() Community, This year's adaptTo() conference in September 2020 will be a *virtual online conference*, and it will be much more than just streaming videos. Look forward for over 35 talks, workshops, panel discussions, social interaction and networking sessions. The agenda will be published in July. We've restarted ticket sales with a completely new pricing, early bird tickets are available till end of July https://adapt.to/tickets For more information please visit us at https://adapt.to or share your thoughts via i...@adaptto.org or #adaptto or at https://adapt.to/linkedin Kind regards from the adaptTo() Team, Stefan
adaptTo() 2020 - Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another four weeks. The new deadline is April 29. So, if you would like to be a speaker, please visit https://adapt.to/cfp - and/or if you know any other potential speakers, please send them our way! I would also like to use this opportunity to remind you that Early Bird tickets are still available. Go to https://adapt.to/tickets before May 31 to take advantage of this offer. As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. A note on the current worldwide situation: We would like to assure you that in the event of a cancellation on our part, the full ticket price will be refunded. Kind regards on behalf of the adaptTo() Team, Stefan P.S.: There is a discount for Apache Committers (any project - Sling, Felix, Jackrabbit) - see https://adapt.to/conference for details.
[jira] [Resolved] (JCRVLT-423) filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags node
[
https://issues.apache.org/jira/browse/JCRVLT-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved JCRVLT-423.
---
Resolution: Not A Problem
fixed version 1.7.6 of the download & unpack logic of the wcm.io content
package maven plugin
> filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags
> node
> ---
>
> Key: JCRVLT-423
> URL: https://issues.apache.org/jira/browse/JCRVLT-423
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.2
>Reporter: Stefan Seifert
>Priority: Major
>
> i've encountered another problem, occurs on 1.1.2 and 1.1.3-SNAPSHOT, not
> with version 1.1.0 of the plugin.
> sample project that contains some content below {{/content/cq:tags}}:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.1.2-validation-issues/tree/master/content-packages/sample-content
> leads to validation failures:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-docviewparser: Invalid XML found:
> Given root node name 'cq:tags' (implicitly given via filename) cannot be
> resolved. The prefix used in the filename must be declared as XML namespace
> in the child docview XML as well!",
> filePath=jcr_root\content\_cq_tags\.content.xml
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/cq:tags/.content.xml' is not contained in any of the filter rules",
> filePath=jcr_root\content\_cq_tags\.content.xml
> {noformat}
> the package content is exactly that what the package manager produced when
> downloading the package, so the package data itself is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-423) filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags node
[
https://issues.apache.org/jira/browse/JCRVLT-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065052#comment-17065052
]
Stefan Seifert commented on JCRVLT-423:
---
FileVault 3.2.8 bundle is installed on the instance.
oh, i see the problem. i'm not downloading the package manually, but using
https://wcm.io/tooling/maven/plugins/wcmio-content-package-maven-plugin/ to
automate the download and extraction. this plugin allows to remove nodes and
attributes that should not be stored in git (e.g. containing last modified
dates) - and removes also orphaned namespace declarations that are leftovers of
those removed attributes. this also removes this namespace declaration for the
file name.
sorry for the noise, i'll see to fix the problem in the plugin and report back.
> filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags
> node
> ---
>
> Key: JCRVLT-423
> URL: https://issues.apache.org/jira/browse/JCRVLT-423
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.2
> Reporter: Stefan Seifert
>Priority: Major
>
> i've encountered another problem, occurs on 1.1.2 and 1.1.3-SNAPSHOT, not
> with version 1.1.0 of the plugin.
> sample project that contains some content below {{/content/cq:tags}}:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.1.2-validation-issues/tree/master/content-packages/sample-content
> leads to validation failures:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-docviewparser: Invalid XML found:
> Given root node name 'cq:tags' (implicitly given via filename) cannot be
> resolved. The prefix used in the filename must be declared as XML namespace
> in the child docview XML as well!",
> filePath=jcr_root\content\_cq_tags\.content.xml
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/cq:tags/.content.xml' is not contained in any of the filter rules",
> filePath=jcr_root\content\_cq_tags\.content.xml
> {noformat}
> the package content is exactly that what the package manager produced when
> downloading the package, so the package data itself is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-422) filevault-package-maven-plugin 1.1.2: jackrabbit-emptyelements filter fails for nodes staring with numbers
[
https://issues.apache.org/jira/browse/JCRVLT-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063578#comment-17063578
]
Stefan Seifert commented on JCRVLT-422:
---
thanks! - problem solved -validated with filevault-package-maven-plugin
1.1.3-SNAPSHOT (after updating dependency to filevault 3.4.5-SNAPSHOT)
> filevault-package-maven-plugin 1.1.2: jackrabbit-emptyelements filter fails
> for nodes staring with numbers
> --
>
> Key: JCRVLT-422
> URL: https://issues.apache.org/jira/browse/JCRVLT-422
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin, vlt
>Affects Versions: 3.4.4, package-maven-plugin-1.1.2
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.6
>
>
> to reproduce the problem build this sample project:
>
> [https://github.com/stefanseifert/filevault-package-maven-plugin-1.1.2-validation-issues/tree/master/content-packages/sample-content]
> this leads (among others) to this error:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-emptyelements: Found empty node
> (used for ordering only) without an accompanying folder which are included in
> the filter with mode=replace. Either remove the empty node or add at least
> the 'jcr:primaryType' attribute to make this node really get replaced.",
> filePath=jcr_root\content\dam\filevaultsample\.content.xml,
> nodePath=/content/dam/filevaultsample/_x0030_123_sample.jpg
> {noformat}
>
> this is wrong, the node is present. the filter seems to fail due to the
> escaped node name {{_x0030_123_sample.jpg}}, which should map to
> {{0123_sample.jpg}} in the file system.
> this problem did not occur with version 1.1.0 of the plugin.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-421) filevault-package-maven-plugin 1.1.2: Empty nodes (used for ordering only) outside filter lead to error
[
https://issues.apache.org/jira/browse/JCRVLT-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063577#comment-17063577
]
Stefan Seifert commented on JCRVLT-421:
---
thanks! - problem solved -validated with filevault-package-maven-plugin
1.1.3-SNAPSHOT (after updating dependency to filevault 3.4.5-SNAPSHOT)
tested with a few projects, detected a new issue: JCRVLT-423
> filevault-package-maven-plugin 1.1.2: Empty nodes (used for ordering only)
> outside filter lead to error
>
>
> Key: JCRVLT-421
> URL: https://issues.apache.org/jira/browse/JCRVLT-421
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin, vlt
>Affects Versions: 3.4.4, package-maven-plugin-1.1.2
> Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.6
>
>
> if you download a package from a live repository with a sub path and the
> instance has much more content in sibling paths the package usually contains
> empty node references to the sister nodes to represent the node ordering.
> with filevault-package-maven-plugin 1.1.2 those node references lead to
> validation errors, failing the build.
> to reproduce the problem build this sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.1.2-validation-issues/tree/master/content-packages/sample-content
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/dam/filevaultsample/jcr:content/folderThumbnail' is not contained
> in any of the filter rules",
> filePath=jcr_root\content\dam\filevaultsample\.content.xml,
> nodePath=/content/dam/filevaultsample/jcr:content/folderThumbnail, line=11,
> column=27
> [INFO] ValidationViolation: "jackrabbit-filter: Ancestor node '/content/dam'
> is not covered by any of the filter rules. Preferably depend on a package
> that provides this node or include it in the filter rules!",
> filePath=jcr_root\content\dam\.content.xml
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/rep:policy'
> is not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/rep:policy, line=5,
> column=18
> [INFO] ValidationViolation: "jackrabbit-filter: Ancestor node '/content/dam'
> is not covered by any of the filter rules. Preferably depend on a package
> that provides this node or include it in the filter rules!",
> filePath=jcr_root\content\.content.xml, nodePath=/content/dam, line=6,
> column=11
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/campaigns' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/campaigns, line=7,
> column=17
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/projects' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/projects, line=8,
> column=16
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/experience-fragments' is not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml,
> nodePath=/content/experience-fragments, line=9, column=28
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/cq:tags' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/cq:tags, line=10,
> column=15
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/usergenerated' is not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/usergenerated,
> line=11, column=21
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/launches' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/launches, line=12,
> column=16
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/communities'
> is not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/communities,
> line=13, column=19
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/sites' is not
> contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/sites, line=14,
> column=13
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/forms' is not
> contained in any of
