[jira] [Updated] (JCRVLT-462) Nodetype validator complains about root node

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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

2020-08-19 Thread GitBox


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

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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

2020-08-19 Thread GitBox


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

2020-08-19 Thread Konrad Windszus (Jira)
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

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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 
> 

[jira] [Updated] (JCRVLT-465) VLT-RCP and Core require DS 1.4 due to constructor injection

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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 
> 

BUILD FAILURE: Jackrabbit Oak - Build # 2856 - Still Failing

2020-08-19 Thread Apache Jenkins Server
The Apache Jenkins build system has built Jackrabbit Oak (build #2856)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/2856/ to 
view the results.

Changes:
No changes
 

Test results:
No tests ran.<>


BUILD FAILURE: Jackrabbit Oak - Build # 2855 - Still Failing

2020-08-19 Thread Apache Jenkins Server
The Apache Jenkins build system has built Jackrabbit Oak (build #2855)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/2855/ to 
view the results.

Changes:
No changes
 

Test results:
No tests ran.<>


[jira] [Created] (JCRVLT-469) Validator for overlapping filter rules

2020-08-19 Thread Konrad Windszus (Jira)
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

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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

2020-08-19 Thread Konrad Windszus (Jira)


 [ 
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

2020-08-19 Thread Konrad Windszus (Jira)
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)