[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 ] Konrad Windszus updated JCRVLT-462: --- Assignee: Konrad Windszus Status: Patch Available (was: Open) PR: https://github.com/apache/jackrabbit-filevault/pull/98/files > 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: package-maven-plugin-1.1.4, 3.4.6 >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)
[GitHub] [jackrabbit-filevault] kwin opened a new pull request #98: JCRVLT-462 no validation error for uncontained root node
kwin opened a new pull request #98: URL: https://github.com/apache/jackrabbit-filevault/pull/98 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JCRVLT-470) VLT-RCP: Expose version via servlet
[ https://issues.apache.org/jira/browse/JCRVLT-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-470: --- Assignee: Konrad Windszus Status: Patch Available (was: Open) PR: https://github.com/apache/jackrabbit-filevault/pull/97 > VLT-RCP: Expose version via servlet > --- > > Key: JCRVLT-470 > URL: https://issues.apache.org/jira/browse/JCRVLT-470 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: RCP >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Minor > Fix For: 3.4.8 > > > There should be an additional REST endpoint which exposes the RCP bundle > version: > https://jackrabbit.apache.org/filevault/rcp.html#Vault_RCP_Server_Bundle. > That allows clients to conditionally enable some features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [jackrabbit-filevault] kwin opened a new pull request #97: JCRVLT-470 expose meta information about ReST endpoint
kwin opened a new pull request #97: URL: https://github.com/apache/jackrabbit-filevault/pull/97 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JCRVLT-470) VLT-RCP: Expose version via servlet
Konrad Windszus created JCRVLT-470: -- Summary: VLT-RCP: Expose version via servlet Key: JCRVLT-470 URL: https://issues.apache.org/jira/browse/JCRVLT-470 Project: Jackrabbit FileVault Issue Type: Improvement Components: RCP Reporter: Konrad Windszus Fix For: 3.4.8 There should be an additional REST endpoint which exposes the RCP bundle version: https://jackrabbit.apache.org/filevault/rcp.html#Vault_RCP_Server_Bundle. That allows clients to conditionally enable some features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCRVLT-465) VLT-RCP and Core require DS 1.4 due to constructor injection
[ https://issues.apache.org/jira/browse/JCRVLT-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-465. Resolution: Fixed > VLT-RCP and Core require DS 1.4 due to constructor injection > > > Key: JCRVLT-465 > URL: https://issues.apache.org/jira/browse/JCRVLT-465 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: RCP >Affects Versions: 3.4.6 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.8 > > > underlined textAlthough with JCRVLT-436 compatibility from a package import > PoV has been restored with Jackrabbit 2.14 (ships with AEM 6.3) it requires > OSGi DS 1.4 due to the usage of constructor injection in > {{RcpTaskManagerImpl}}. AEM 6.3 still ships with DS 1.3 and only AEM 6.4 > supports DS 1.4. > The log message which can be seen in the logs is > {code} > 11.08.2020 17:21:02.359 *ERROR* [qtp884469201-165] > org.apache.jackrabbit.vault.rcp > [org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl(3004)] Error during > instantiation of the implementation object (java.lang.InstantiationException: > org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl) > java.lang.InstantiationException: > org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl > at java.lang.Class.newInstance(Unknown Source) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:237) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344) > at org.apache.felix.framework.Felix.getService(Felix.java:3700) > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > at > org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72) > at > org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985) > at > org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201) > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1118) > at > org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344) > at org.apache.felix.framework.Felix.getService(Felix.java:3700) > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > at > org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72) > at > org.apache.felix.scr.impl.manager.DependencyManager.getService(DependencyManager.java:1461) > at > org.apache.felix.scr.impl.manager.DependencyManager.getService(DependencyManager.java:1434) > at > org.apache.felix.scr.impl.manager.ComponentContextImpl.locateService(ComponentContextImpl.java:147) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.createServlet(SlingServletResolver.java:968) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.bindServlet(SlingServletResolver.java:930) > at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:224) > at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39) > at > org.apache.felix.scr.impl.in
[jira] [Updated] (JCRVLT-465) VLT-RCP and Core require DS 1.4 due to constructor injection
[ https://issues.apache.org/jira/browse/JCRVLT-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-465: --- Status: In Progress (was: Patch Available) Fixed in https://github.com/apache/jackrabbit-filevault/commit/52a19aca994d74f2f1345ae828ff123eb28609be. > VLT-RCP and Core require DS 1.4 due to constructor injection > > > Key: JCRVLT-465 > URL: https://issues.apache.org/jira/browse/JCRVLT-465 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: RCP >Affects Versions: 3.4.6 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.8 > > > underlined textAlthough with JCRVLT-436 compatibility from a package import > PoV has been restored with Jackrabbit 2.14 (ships with AEM 6.3) it requires > OSGi DS 1.4 due to the usage of constructor injection in > {{RcpTaskManagerImpl}}. AEM 6.3 still ships with DS 1.3 and only AEM 6.4 > supports DS 1.4. > The log message which can be seen in the logs is > {code} > 11.08.2020 17:21:02.359 *ERROR* [qtp884469201-165] > org.apache.jackrabbit.vault.rcp > [org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl(3004)] Error during > instantiation of the implementation object (java.lang.InstantiationException: > org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl) > java.lang.InstantiationException: > org.apache.jackrabbit.vault.rcp.impl.RcpTaskManagerImpl > at java.lang.Class.newInstance(Unknown Source) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:237) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344) > at org.apache.felix.framework.Felix.getService(Felix.java:3700) > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > at > org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72) > at > org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985) > at > org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201) > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1118) > at > org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344) > at org.apache.felix.framework.Felix.getService(Felix.java:3700) > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > at > org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72) > at > org.apache.felix.scr.impl.manager.DependencyManager.getService(DependencyManager.java:1461) > at > org.apache.felix.scr.impl.manager.DependencyManager.getService(DependencyManager.java:1434) > at > org.apache.felix.scr.impl.manager.ComponentContextImpl.locateService(ComponentContextImpl.java:147) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.createServlet(SlingServletResolver.java:968) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.bindServlet(SlingServletResolver.java:930) > at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMeth
[jira] [Created] (JCRVLT-469) Validator for overlapping filter rules
Konrad Windszus created JCRVLT-469: -- Summary: Validator for overlapping filter rules Key: JCRVLT-469 URL: https://issues.apache.org/jira/browse/JCRVLT-469 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Reporter: Konrad Windszus Fix For: 3.4.8 A validator which checks for overlapping filter rules in nested packages of containers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCRVLT-468) Skip "validate-files" when "validate-package" is executed later on also in case of forked executions
[ https://issues.apache.org/jira/browse/JCRVLT-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-468. Assignee: Konrad Windszus Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/4fec8fe8424a9593c46a4b84fdbd66362f972d2e. > Skip "validate-files" when "validate-package" is executed later on also in > case of forked executions > > > Key: JCRVLT-468 > URL: https://issues.apache.org/jira/browse/JCRVLT-468 > 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.6 > > > Currently the mojo {{validate-files}} is automatically skipped in case > {{validate-package}} is executed later on. This does not work though for > forked lifecycle executions yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCRVLT-467) Thread Context ClassLoader destroyed in validate-files mojo
[ https://issues.apache.org/jira/browse/JCRVLT-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-467. Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/4fec8fe8424a9593c46a4b84fdbd66362f972d2e. > Thread Context ClassLoader destroyed in validate-files mojo > --- > > Key: JCRVLT-467 > URL: https://issues.apache.org/jira/browse/JCRVLT-467 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.1.0 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.6 > > > Due to the code called in > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/b4d0cc4e2bc81d99b1370af6ac71b39c9a03fb97/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/ValidateFilesMojo.java#L276 > the Thread Context Classloader (TCCL) is modified and after the call is no > longer the plugin classloader. > That prevents loading resources from the TCCL like necessary for loading maps > in > https://github.com/Netcentric/aem-classification/tree/master/aem-classification-validator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCRVLT-468) Skip "validate-files" when "validate-package" is executed later on also in case of forked executions
[ https://issues.apache.org/jira/browse/JCRVLT-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-468: --- Fix Version/s: (was: 3.4.8) package-maven-plugin-1.1.6 > Skip "validate-files" when "validate-package" is executed later on also in > case of forked executions > > > Key: JCRVLT-468 > URL: https://issues.apache.org/jira/browse/JCRVLT-468 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.1.6 > > > Currently the mojo {{validate-files}} is automatically skipped in case > {{validate-package}} is executed later on. This does not work though for > forked lifecycle executions yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCRVLT-468) Skip "validate-files" when "validate-package" is executed later on also in case of forked executions
Konrad Windszus created JCRVLT-468: -- Summary: Skip "validate-files" when "validate-package" is executed later on also in case of forked executions Key: JCRVLT-468 URL: https://issues.apache.org/jira/browse/JCRVLT-468 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Reporter: Konrad Windszus Fix For: 3.4.8 Currently the mojo {{validate-files}} is automatically skipped in case {{validate-package}} is executed later on. This does not work though for forked lifecycle executions yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)