[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)
[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 OSGi bundles/configurations
and subpackages!",
[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)
[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)
[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)
[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)
[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)
[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)
[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)
[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 the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/forms, line=15,
> column=13
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/catalogs' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/catalogs, line=16,
> column=16
> [ERROR] ValidationViolation:
[jira] [Created] (JCRVLT-423) filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags node
Stefan Seifert created JCRVLT-423:
-
Summary: 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
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-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=17063153#comment-17063153
]
Stefan Seifert commented on JCRVLT-421:
---
this rep:policy node reference is contained in what is exported by the package
manager when downloading and extracking the package.
i think it is important to allow this workflow without the need for manually
changing the content and without producing validation errors:
* upload content from package project
* change the content in the running instance
* download package and extract it to persist the updated content in the scm repo
> 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
>Affects Versions: package-maven-plugin-1.1.2
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> 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 the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/forms, line=15,
> column=13
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
[jira] [Created] (JCRVLT-422) filevault-package-maven-plugin 1.1.2: jackrabbit-emptyelements filter fails for nodes staring with numbers
Stefan Seifert created JCRVLT-422:
-
Summary: 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
Affects Versions: package-maven-plugin-1.1.2
Reporter: Stefan Seifert
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] [Updated] (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:all-tabpanel
]
Stefan Seifert updated JCRVLT-421:
--
Component/s: package maven plugin
> 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
>Affects Versions: package-maven-plugin-1.1.2
>Reporter: Stefan Seifert
>Priority: Major
>
> 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 the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/forms, line=15,
> column=13
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/catalogs' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/catalogs, line=16,
> column=16
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/screens' is
> not contained in any of the filter rules",
> filePath=jcr_root\content\.content.xml, nodePath=/content/screens, line=17,
> column=15
> [ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/community' is
> not contained in any of the
[jira] [Created] (JCRVLT-421) filevault-package-maven-plugin 1.1.2: Empty nodes (used for ordering only) outside filter lead to error
Stefan Seifert created JCRVLT-421:
-
Summary: 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
Affects Versions: package-maven-plugin-1.1.2
Reporter: Stefan Seifert
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 the filter rules", filePath=jcr_root\content\.content.xml,
nodePath=/content/forms, line=15, column=13
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/catalogs' is
not contained in any of the filter rules",
filePath=jcr_root\content\.content.xml, nodePath=/content/catalogs, line=16,
column=16
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/screens' is not
contained in any of the filter rules", filePath=jcr_root\content\.content.xml,
nodePath=/content/screens, line=17, column=15
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/community' is
not contained in any of the filter rules",
filePath=jcr_root\content\.content.xml, nodePath=/content/community, line=18,
column=17
[INFO] ValidationViolation: "jackrabbit-filter: Ancestor node '/content' is not
covered by any of the filter rules but that node is a given root (either by a
dependency or by the known roots). Remove that node!",
filePath=jcr_root\content\.content.xml
[INFO] ValidationViolation: "jackrabbit-filter: Ancestor node '/' is not
covered by any of the filter rules but that node
[jira] [Commented] (JCRVLT-389) Optionally support Maven Filtering during packaging
[ https://issues.apache.org/jira/browse/JCRVLT-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006920#comment-17006920 ] Stefan Seifert commented on JCRVLT-389: --- lgtm, thanks! > Optionally support Maven Filtering during packaging > --- > > Key: JCRVLT-389 > URL: https://issues.apache.org/jira/browse/JCRVLT-389 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.0 > > Attachments: 191227_myproject1-ui.apps-1.0.0-SNAPSHOT.zip > > > In some cases it would be useful to apply some filtering before a file is > being included in the package. Instead of filtering it as separate goal via > copy resources this filtering should be optionally supported by the package > goal (similar to what the maven-war-plugin offers in > https://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCRVLT-389) Optionally support Maven Filtering during packaging
[ https://issues.apache.org/jira/browse/JCRVLT-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-389: -- Attachment: 191227_myproject1-ui.apps-1.0.0-SNAPSHOT.zip > Optionally support Maven Filtering during packaging > --- > > Key: JCRVLT-389 > URL: https://issues.apache.org/jira/browse/JCRVLT-389 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.0 > > Attachments: 191227_myproject1-ui.apps-1.0.0-SNAPSHOT.zip > > > In some cases it would be useful to apply some filtering before a file is > being included in the package. Instead of filtering it as separate goal via > copy resources this filtering should be optionally supported by the package > goal (similar to what the maven-war-plugin offers in > https://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-389) Optionally support Maven Filtering during packaging
[
https://issues.apache.org/jira/browse/JCRVLT-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004040#comment-17004040
]
Stefan Seifert commented on JCRVLT-389:
---
i've basically the same warnings on windows - only this line is missing:
{noformat}
[WARNING] ValidationViolation: "jackrabbit-packagetype: Package of type 'MIXED'
is legacy. Use one of the other types instead!",
filePath=META-INF/vault/properties.xml
{noformat}
i've attached the generated ZIP package with the double size:
[^191227_myproject1-ui.apps-1.0.0-SNAPSHOT.zip]
the duplicated folders start at
* /apps/epsilon65Project/clientlibs/components,
/apps/epsilon65Project/clientlibs/i18n (should not exist, is below
/apps/epsilon65Project/core)
* /apps/epsilon65Project/core/epsilon65Project* (should not exist, is below
/apps/epsilon65Project/clientlibs)
> Optionally support Maven Filtering during packaging
> ---
>
> Key: JCRVLT-389
> URL: https://issues.apache.org/jira/browse/JCRVLT-389
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
>
> In some cases it would be useful to apply some filtering before a file is
> being included in the package. Instead of filtering it as separate goal via
> copy resources this filtering should be optionally supported by the package
> goal (similar to what the maven-war-plugin offers in
> https://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-389) Optionally support Maven Filtering during packaging
[ https://issues.apache.org/jira/browse/JCRVLT-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987306#comment-16987306 ] Stefan Seifert commented on JCRVLT-389: --- i tested the feature with my test project. this project uses "manual filtering" without the new feature: https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps pom config: https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/blob/f4a74028f3f7f0a094a74bbb6b9c82c816afb415/content-packages/ui.apps/pom.xml#L26-L56 the same project on a branch uses the new flag: https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/feature/JCRVLT-389-maven-filtering/content-packages/ui.apps pom config: https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/blob/3817cecd3f11b550db4b863a81c12545ae5be89f/content-packages/ui.apps/pom.xml#L27-L40 the result is strange - using the branch the resulting content package has a lot of duplicated files on folder positions not included in the source files - and the resulting ZIP file has nearly twice the size as the original file with the manual filtering. > Optionally support Maven Filtering during packaging > --- > > Key: JCRVLT-389 > URL: https://issues.apache.org/jira/browse/JCRVLT-389 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.0 > > > In some cases it would be useful to apply some filtering before a file is > being included in the package. Instead of filtering it as separate goal via > copy resources this filtering should be optionally supported by the package > goal (similar to what the maven-war-plugin offers in > https://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975794#comment-16975794
]
Stefan Seifert commented on JCRVLT-354:
---
looks good, the false warnings are gone!
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975684#comment-16975684
]
Stefan Seifert commented on JCRVLT-354:
---
the warnings with the backslashes are issued _before_ the code halts at this
codeline (and in this code line it seems to translate the paths correct - but
too late).
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975257#comment-16975257
]
Stefan Seifert commented on JCRVLT-354:
---
here is an example of the entryNames collection with the mixed slashes:
{noformat}
[
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
jcr_root/content/.content.xml
jcr_root\content\myproject1\en\.content.xml
jcr_root\content\dam\myproject1\nature.jpg
META-INF\vault
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
jcr_root\content\myproject1\.content.xml
META-INF\vault\filter.xml
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
jcr_root\content\myproject1\
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content
META-INF\vault\config.xml
META-INF\vault\properties.xml
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content
jcr_root\content\dam\myproject1\prague.jpg\.content.xml
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir
jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
jcr_root\content\dam\myproject1\prague.jpg
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir
META-INF\vault\settings.xml
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
META-INF\MANIFEST.MF
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\original.dir
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions
jcr_root\content\dam\myproject1\
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\original.dir\.content.xml
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
META-INF
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
jcr_root/.content.xml
jcr_root\content\myproject1\en
jcr_root\content\dam\myproject1\chicago.jpg
jcr_root\content\dam\myproject1\nature.jpg\_jcr_content
jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\original
META-INF\vault\
jcr_root\content\dam\myproject1\nature.jpg\.content.xml
jcr_root/content/dam/.content.xml
jcr_root\content\dam\myproject1\.content.xml
jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions
]
{noformat}
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974213#comment-16974213
]
Stefan Seifert commented on JCRVLT-354:
---
i looked a bit into it - the ZIP files are created using the plexus archiver
infrastructure. this has some tweaks here and there for converting backslashes
to slashes, but it does not seem to work for the resources added from the
workDirectory. i tried adding a custom FileMapper for the FileSet, but that
affected only the file names, not the directory names. needs a deeper look.
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969537#comment-16969537
]
Stefan Seifert commented on JCRVLT-354:
---
this was halfaway the fix - the entry set that was compared with already
contained a mixture of forward and backward slashes.
this is fixed with this patch: [^JCRVLT-354-normalize-windows-paths.patch]
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING]
[jira] [Updated] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-354:
--
Attachment: JCRVLT-354-normalize-windows-paths.patch
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log,
> JCRVLT-354-normalize-windows-paths.patch
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967881#comment-16967881
]
Stefan Seifert commented on JCRVLT-355:
---
bq. As alternative you could first copy from src to target/something with
filtering and then set parameterjcrRootSourceDirectory to that target filter.
i was able to find a configuration for the {{ui.apps}} package that allows to
build a package including filtering some resources:
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/commit/160475a0c544e7f1182dc02068fd743dce83a2c0
i had to set the packageType to "mixed" (also "application" should be the
correct one) to avoid validation errors.
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967869#comment-16967869
]
Stefan Seifert commented on JCRVLT-354:
---
retestet wit current snapshot and the project
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
the build failure does no longer occur - but the WARNINGs from the original
report are still present (in the "package" step, not in the "validate-package"
step).
build log attached: [^101105_build.log]
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Updated] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-354:
--
Attachment: 101105_build.log
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
> Attachments: 101105_build.log
>
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964686#comment-16964686
]
Stefan Seifert commented on JCRVLT-355:
---
then i think we can set this ticket to resolved
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-389) Optionally support Maven Filtering during packaging
[ https://issues.apache.org/jira/browse/JCRVLT-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964685#comment-16964685 ] Stefan Seifert commented on JCRVLT-389: --- sounds good! > Optionally support Maven Filtering during packaging > --- > > Key: JCRVLT-389 > URL: https://issues.apache.org/jira/browse/JCRVLT-389 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.0 > > > In some cases it would be useful to apply some filtering before a file is > being included in the package. Instead of filtering it as separate goal via > copy resources this filtering should be optionally supported by the package > goal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964400#comment-16964400
]
Stefan Seifert commented on JCRVLT-354:
---
i'm not sure if its the same problem, but with the latest 1.0.5-SNAPSHOT
version of the plugin i do not only get the warnings described above, but the
build fails completely (with the sample-content package project listed above):
{noformat}
[INFO] --- filevault-package-maven-plugin:1.0.5-SNAPSHOT:validate-package
(default-validate-package) @ mycompany.myprojectgroup.myproject1.sample-content
---
[INFO] Start validating package
'D:\Develop\github\filevault-package-maven-plugin-1.0.4-validation-issues\content-packages\sample-content\target\myproject1-sample-content-1.0.0-SNAPSHOT.zip'...
[INFO] Using 9 validators for package of type CONTENT: jackrabbit-filter
(org.apache.jackrabbit.vault.validation.spi.impl.AdvancedFilterValidator),
jackrabbit-properties
(org.apache.jackrabbit.vault.validation.spi.impl.AdvancedPropertiesValidator),
jackrabbit-docviewparser
(org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator),
jackrabbit-dependencies
(org.apache.jackrabbit.vault.validation.spi.impl.DependencyValidator),
jackrabbit-emptyelements
(org.apache.jackrabbit.vault.validation.spi.impl.EmptyElementsValidator),
jackrabbit-mergelimitations
(org.apache.jackrabbit.vault.validation.spi.impl.MergeLimitationsValidator),
jackrabbit-oakindex
(org.apache.jackrabbit.vault.validation.spi.impl.OakIndexDefinitionValidator),
jackrabbit-packagetype
(org.apache.jackrabbit.vault.validation.spi.impl.PackageTypeValidator),
jackrabbit-primarynodetype
(org.apache.jackrabbit.vault.validation.spi.impl.PrimaryNodeTypeValidator)
[WARNING] ValidationViolation: "jackrabbit-filter: Filter root's ancestor
'/content/dam' is not covered by any of the specified dependencies nor a valid
root.", filePath=META-INF\vault\filter.xml
[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, nodePath=/content/dam, line=4
[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=7
[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=10
[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=15
[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=16
[INFO] ValidationViolation: "jackrabbit-filter: Ancestor node '/content' is not
covered by any of the filter rules but that node is a given root (either by a
dependency or by the known roots). Remove that node!",
filePath=jcr_root\content\.content.xml, nodePath=/content, line=4
[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=14
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/forms' is not
contained in any of the filter rules", filePath=jcr_root\content\.content.xml,
nodePath=/content/forms, line=17
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/community' is
not contained in any of the filter rules",
filePath=jcr_root\content\.content.xml, nodePath=/content/community, line=18
[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=9
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/screens' is not
contained in any of the filter rules", filePath=jcr_root\content\.content.xml,
nodePath=/content/screens, line=11
[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
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/catalogs' is
not contained in any of the filter rules",
filePath=jcr_root\content\.content.xml, nodePath=/content/catalogs, line=12
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/content/cq:tags' is not
contained in any of the filter rules",
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964398#comment-16964398
]
Stefan Seifert commented on JCRVLT-355:
---
i can confirm that it works with 1.0.5-SNAPSHOT for conf-content (but only
after fixing invalid filter rules reported with the latest snapshot of the
plugin):
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/commit/2eeae01e72a502347ede8081d10d4ea49ac64849
for ui-apps i get the same errors as listed in your commet using 1.0.5-SNAPSHOT.
what i want to achieve is to maven-filter some files in the client library
folder - e.g. for replacing "${project.version}-${buildNumber}" in the
epsilon65Project.all clientlib .content.xml in the final package. i cannot do
this in the source folder, as it should replace the variables only when
building the package. how is this possible without manually copying (and
filtering) the files using build-helper-maven-plugin together wit the latest
filevaule-package-maven-plugin?
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.0
>
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911050#comment-16911050
]
Stefan Seifert commented on JCRVLT-355:
---
concerning the 2nd test project:
{quote}
if you set the root directoy to vault-work, it works:
{code:xml}
${project.build.directory}/vault-work
{code}
{quote}
this does not work (neither with package plugin 1.0.3 or 1.0.4), as the package
then only contains the output produced by the {{build-helper-maven-plugin}},
and not the other content.
but let's first focus on the simpler 1st test project before trying to solve
the interaction of those two plugins.
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911037#comment-16911037
]
Stefan Seifert commented on JCRVLT-355:
---
concerning the 1st test project:
this does not work when installing the package:
{code:xml}
{code}
it does not create {{/conf/myproject1/settings/wcm}} or anything below it.
it is only creates the path when i add a third include pattern like
{code:xml}
{code}
but this is than not the same filter as the initial one as it also
includes/overwrite the node {{/conf/myproject1/settings}}.
and technically - even if the filter expression can be made more elegant
somehow - it should not lead to an error when building the package?
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910550#comment-16910550
]
Stefan Seifert commented on JCRVLT-355:
---
this special configuration is only used on the 2nd project - the first one is
simpler but shows the same problem.
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910533#comment-16910533
]
Stefan Seifert commented on JCRVLT-355:
---
i've tested it on windows 10
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910531#comment-16910531
]
Stefan Seifert commented on JCRVLT-354:
---
maybe, i tested it only on windows 10
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Commented] (JCRVLT-279) Emit warning/error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909687#comment-16909687
]
Stefan Seifert commented on JCRVLT-279:
---
i've found problems with this new check - reported in JCRVLT-355
> Emit warning/error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
>
>
> Key: JCRVLT-279
> URL: https://issues.apache.org/jira/browse/JCRVLT-279
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: package-maven-plugin-1.0.4
>
>
> Due to errorneous project setup it may sometimes happen that the
> {{jcrRootSourceDirectory}} inadvertently contains the to be embedded file.
> Since the {{jcrRootSourceDirectory}} is having a higher precedence all files
> in there overwrite previously embedded files. In that case a warning/error
> should be emitted. The same for sub packages.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
Stefan Seifert created JCRVLT-355:
-
Summary: False error in case embedded file/subpackage is
overwritten by jcrRootSourceDirectory
Key: JCRVLT-355
URL: https://issues.apache.org/jira/browse/JCRVLT-355
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.4
Reporter: Stefan Seifert
i've found problem with the check introduced with JCRVLT-279 - or i do not
understand why the check leads to a failure in my case.
i've two projects where this happens:
1. conf-content:
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
fails with:
{noformat}
[ERROR] Failed to execute goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
(default-package) on project mycompany.myprojectgroup.myproject1.conf-content:
org.apache.maven.plugin.MojoFailureException: Found duplicate files in content
package, most probably you have overlapping filter roots or you embed a file
which is already there in 'jcrRootSourceDirectory'. For details check the
nested exception!: Duplicate file
jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
attribute is 'fail'. {noformat}
2. ui.apps
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
fails with:
{noformat}
[ERROR] Failed to execute goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
(default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
org.apache.maven.plugin.MojoFailureException: Found duplicate files in content
package, most probably you have overlapping filter roots or you embed a file
which is already there in 'jcrRootSourceDirectory'. For details check the
nested exception!: Duplicate file
jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
duplicate attribute is 'fail'.
{noformat}
the second project is a special case because in some files in the "clientlibs"
folder placeholders are replaced using maven resource filtering, if the
corresponding build-helper-maven-plugin definition is removed the build works.
but the first project is really simple project.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-354:
--
Description:
the new check introduced in JCRVLT-321 produces false warnings in my case - or
i do not understand why the warning occurs.
here is a sample project:
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
i can understand these warnings
{noformat}
[WARNING] File content-packages\sample-content\jcr_root\.content.xml not
covered by a filter rule and therefore not contained in the resulting package
[WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
by a filter rule and therefore not contained in the resulting package
{noformat}
although it's a pity they are reported because usually these .content.xml files
"above" the filter paths help creating in between nodes when the package is
extracted and the parent paths of the filter do not exist yet.
but i do not understand these warnings as the files are definitely included in
the filter:
{noformat}
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\original
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\original.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
content-packages\sample-content\jcr_root\content\myproject1\.content.xml not
covered by a filter rule and therefore not contained in the resulting package
[WARNING] File
[jira] [Commented] (JCRVLT-321) Warn for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909677#comment-16909677
]
Stefan Seifert commented on JCRVLT-321:
---
i've found problems with this new check - reported in JCRVLT-354
> Warn for files not being included in the package due to being outside of
> filter roots
> -
>
> Key: JCRVLT-321
> URL: https://issues.apache.org/jira/browse/JCRVLT-321
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.3
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.4
>
>
> Currently only those files/folders are added to the content package which are
> somehow covered by filter rules. This is not obvious and a warning should be
> emitted whenever there is a folder/file being part of {{jcrSourceDirectory}}
> which is not covered.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
Stefan Seifert created JCRVLT-354:
-
Summary: False warnings for files not being included in the
package due to being outside of filter roots
Key: JCRVLT-354
URL: https://issues.apache.org/jira/browse/JCRVLT-354
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.4
Reporter: Stefan Seifert
the new check introduced in JCRVLT-321 produces false warnings in my case - or
i do not understand why the warning occurs.
here is a sample project:
https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
i can understand these warnings
{noformat}
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
{noformat}
although it's a pity they are reported because usually these .content.xml files
"above" the filter paths help creating in between nodes when the package is
extracted and the parent paths of the filter do not exist yet.
but i do not understand these warnings as the files are definitely included in
the filter:
{noformat}
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
C:\temp\mycompany.myprojectgroup.myproject1\content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
not covered by a filter rule and therefore not contained in the resulting
package
[WARNING] File
[jira] [Updated] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest
[ https://issues.apache.org/jira/browse/JCRVLT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-256: -- Status: Patch Available (was: Open) patch attached that adds a test case to reproduce the problem in the IT and fix the NPE. > Package Maven Plugin: NPE when dependency has no manifest > - > > Key: JCRVLT-256 > URL: https://issues.apache.org/jira/browse/JCRVLT-256 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Stefan Seifert >Priority: Minor > Fix For: package-maven-plugin-1.0.2 > > Attachments: JCRVLT-256.patch > > > when the package project contains a dependency that has not manifest at all > (e.g. javax.inject) the code throws an NPE. > of course it does not make much sense to have such an dependency, but it > should not lead to an err.r -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest
[ https://issues.apache.org/jira/browse/JCRVLT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-256: -- Attachment: JCRVLT-256.patch > Package Maven Plugin: NPE when dependency has no manifest > - > > Key: JCRVLT-256 > URL: https://issues.apache.org/jira/browse/JCRVLT-256 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Stefan Seifert >Priority: Minor > Fix For: package-maven-plugin-1.0.2 > > Attachments: JCRVLT-256.patch > > > when the package project contains a dependency that has not manifest at all > (e.g. javax.inject) the code throws an NPE. > of course it does not make much sense to have such an dependency, but it > should not lead to an err.r -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JCRVLT-256) Package Maven Plugin: NPE when dependency has no manifest
Stefan Seifert created JCRVLT-256: - Summary: Package Maven Plugin: NPE when dependency has no manifest Key: JCRVLT-256 URL: https://issues.apache.org/jira/browse/JCRVLT-256 Project: Jackrabbit FileVault Issue Type: Bug Components: package maven plugin Affects Versions: package-maven-plugin-1.0.1 Reporter: Stefan Seifert Priority: Minor Fix For: package-maven-plugin-1.0.2 when the package project contains a dependency that has not manifest at all (e.g. javax.inject) the code throws an NPE. of course it does not make much sense to have such an dependency, but it should not lead to an err.r -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JCRVLT-252) Package Maven Plugin: Update to htl-maven-plugin 1.1.2
Stefan Seifert created JCRVLT-252: - Summary: Package Maven Plugin: Update to htl-maven-plugin 1.1.2 Key: JCRVLT-252 URL: https://issues.apache.org/jira/browse/JCRVLT-252 Project: Jackrabbit FileVault Issue Type: Bug Components: package maven plugin Reporter: Stefan Seifert Priority: Minor Fix For: package-maven-plugin-1.0.1 please update to version 1.1.2 of the htl-maven-plugin (released today). the previous version had issues on windows machines, letting the filevault package plugin integration tests fail on windows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCRVLT-252) Package Maven Plugin: Update to htl-maven-plugin 1.1.2
[ https://issues.apache.org/jira/browse/JCRVLT-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-252: -- Attachment: JCRVLT-252.patch > Package Maven Plugin: Update to htl-maven-plugin 1.1.2 > -- > > Key: JCRVLT-252 > URL: https://issues.apache.org/jira/browse/JCRVLT-252 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Reporter: Stefan Seifert >Priority: Minor > Fix For: package-maven-plugin-1.0.1 > > Attachments: JCRVLT-252.patch > > > please update to version 1.1.2 of the htl-maven-plugin (released today). > the previous version had issues on windows machines, letting the filevault > package plugin integration tests fail on windows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCRVLT-252) Package Maven Plugin: Update to htl-maven-plugin 1.1.2
[ https://issues.apache.org/jira/browse/JCRVLT-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-252: -- Status: Patch Available (was: Open) > Package Maven Plugin: Update to htl-maven-plugin 1.1.2 > -- > > Key: JCRVLT-252 > URL: https://issues.apache.org/jira/browse/JCRVLT-252 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Reporter: Stefan Seifert >Priority: Minor > Fix For: package-maven-plugin-1.0.1 > > Attachments: JCRVLT-252.patch > > > please update to version 1.1.2 of the htl-maven-plugin (released today). > the previous version had issues on windows machines, letting the filevault > package plugin integration tests fail on windows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCRVLT-230) Allow to give an explicit directory as source for META-INF/vault
[
https://issues.apache.org/jira/browse/JCRVLT-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16278489#comment-16278489
]
Stefan Seifert commented on JCRVLT-230:
---
in wcm.io content package plugin we used a folder
{{src/main/package-definition}} as default folder for things like filter.xml
and thumbnail.png.
> Allow to give an explicit directory as source for META-INF/vault
>
>
> Key: JCRVLT-230
> URL: https://issues.apache.org/jira/browse/JCRVLT-230
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Konrad Windszus
>
> Currently the {{META-INF/vault}} structure within the packages is built from
> {{/META-INF/vault}}.
> This directory is used for two purposes
> # It receives the generated filter.xml, the merged properties.xml, the
> config.xml and the settings.xml
> # It acts as a source for the resulting package's META-INF/vault
> Not all meta files below META-INF/vault are being generated through the
> plugin itself. Some need to be written manually to {{workDirectory}} with the
> help of the {{maven-resource-plugin}}.
> It would be good to allow to give an explicit source directory for the
> META-INF/vault directory (similar to {{jcrSourceDirectory}}) separated from
> {{workDirectory}}. This would allow to e.g. specify the packages thumbnail
> image, without being forced to copy it over to from src to target.
> In addition this parameter should clearly define which meta files are
> generated by the filevault-package-maven-plugin and are therefore never
> considered, even if they are located in the given META-INF/vault source
> directory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-239) Package Maven Plugin: Add "accessControlHandling" property
[ https://issues.apache.org/jira/browse/JCRVLT-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16274473#comment-16274473 ] Stefan Seifert commented on JCRVLT-239: --- thanks! (although the new parameter name is not backwards compatible for drop in-replacement of the [wcm.io content package plugin|http://wcm.io/tooling/maven/plugins/wcmio-content-package-maven-plugin/] - but we can document the migration change) > Package Maven Plugin: Add "accessControlHandling" property > -- > > Key: JCRVLT-239 > URL: https://issues.apache.org/jira/browse/JCRVLT-239 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.0 >Reporter: Stefan Seifert > Fix For: package-maven-plugin-1.0.1 > > Attachments: JCRVLT-239-v2.patch, JCRVLT-239-v3.patch, > JCRVLT-239.patch > > > currently, it is only possible indirectly via the "properties" property to > set the "acHandling" package parameter. furthermore it is not mentioned at > all in the plugin docs, nor its possible values. > as the "acHandling" package property is used quite often in package > definitions it would be useful to have a property in the mojo itself, same as > it is the case for "requiresRoot", "allowIndexDefinitions", "packageType". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCRVLT-240) Package Maven Plugin: Support for package thumbnails
[
https://issues.apache.org/jira/browse/JCRVLT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270645#comment-16270645
]
Stefan Seifert commented on JCRVLT-240:
---
bq. IIUC you patch correctly, it always overwrites the .content.xml, which
should only happen if it doesn't exist yet.
checked again - this is not the case. the helper method {{copyFile}] does
nothing if the target already exists.
what is always copied is the thumbnail image - if it is set in the plugin
config explicitly and exists.
> Package Maven Plugin: Support for package thumbnails
>
>
> Key: JCRVLT-240
> URL: https://issues.apache.org/jira/browse/JCRVLT-240
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Stefan Seifert
> Fix For: package-maven-plugin-1.0.1
>
> Attachments: JCRVLT-240.patch
>
>
> adding package thumbnails for the generated packages is a but cumbersome
> currently - one has to know exactly the internal path of the thumbnail image
> in the package format, and also add a ".content.xml" in the definition folder.
> it would be nice to have a "thumbnailImage" parameter which accepts a path to
> a thumbnail PNG file - and does the correct placement in the folder and
> generation of the ".content.xml" then automatically.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-245) Package Maven Plugin: ProjectBuilder.verifyPackageProperty swaps expected/actual value
[ https://issues.apache.org/jira/browse/JCRVLT-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-245: -- Status: Patch Available (was: Open) > Package Maven Plugin: ProjectBuilder.verifyPackageProperty swaps > expected/actual value > -- > > Key: JCRVLT-245 > URL: https://issues.apache.org/jira/browse/JCRVLT-245 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.0 >Reporter: Stefan Seifert >Priority: Trivial > Fix For: package-maven-plugin-1.0.1 > > Attachments: JCRVLT-245.patch > > > the helper method ProjectBuilder.verifyPackageProperty displays a wrong > message when the comparison fails - actual and expected value are swapped. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
