Include all nodes in the filter.xml #2045

kwin · 2019-09-17T14:23:17Z

Remove invalid merge option on include/exclude elements.
This closes #2044

update-changelog · 2019-09-17T14:23:26Z

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would update the CHANGELOG.md file with this pull request.

kwin · 2019-09-17T14:24:04Z

This obsoletes #2032

kwin · 2019-09-17T14:35:37Z

With this PR only the following issues are raised with the new filevault-package-maven-plugin

[INFO] --- filevault-package-maven-plugin:1.0.5-SNAPSHOT:validate-package (default-validate-package) @ acs-aem-commons-ui.content ---
[WARNING] The version should not be given if the dependency is specified with 'groupId' and 'artifactId' as the version will be looked up from the Maven dependencies
[INFO] Start validating package '/Users/konradwindszus/git/acs-aem-commons/ui.content/target/acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip'...
[INFO] Using validators: jackrabbit-properties (org.apache.jackrabbit.filevault.maven.packaging.validator.impl.AdvancedPropertiesValidator), jackrabbit-filter (org.apache.jackrabbit.filevault.maven.packaging.validator.impl.AdvancedFilterValidator), jackrabbit-oakindex (org.apache.jackrabbit.filevault.maven.packaging.validator.impl.OakIndexDefinitionValidator)
[INFO] Filter root's ancestor '/etc/designs' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/content/dam' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/etc/notification' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/var/workflow/instances' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/etc/cloudservices' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/etc/workflow/instances' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/home/users' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/home/users/system' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/oak:index' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/etc/clientlibs' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/etc/dam/video' is not covered by any of the specified dependencies.
[INFO] Filter root's ancestor '/home/groups' is not covered by any of the specified dependencies.
[ERROR] ValidationViolation: "Package contains filter rule overwriting a potential index definition below '/oak:index/rep:policy'.", filePath=META-INF/vault/filter.xml
[ERROR] ValidationViolation: "Node /etc/acs-commons/redirect-maps/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/redirect-maps/_rep_policy.xml, nodePath=/etc/acs-commons/redirect-maps/rep:policy/allow, line=8
[ERROR] ValidationViolation: "Node /etc/acs-commons/redirect-maps/rep:policy is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/redirect-maps/_rep_policy.xml, nodePath=/etc/acs-commons/redirect-maps/rep:policy, line=3
[ERROR] ValidationViolation: "Node /etc/acs-commons/qr-code/jcr:content/config is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/qr-code/.content.xml, nodePath=/etc/acs-commons/qr-code/jcr:content/config, line=11
[ERROR] ValidationViolation: "Node /etc/acs-commons/bulk-workflow-manager/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/bulk-workflow-manager/_rep_policy.xml, nodePath=/etc/acs-commons/bulk-workflow-manager/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Node /etc/acs-commons/bulk-workflow-manager/rep:policy is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/bulk-workflow-manager/_rep_policy.xml, nodePath=/etc/acs-commons/bulk-workflow-manager/rep:policy, line=3
[ERROR] ValidationViolation: "Node /etc/acs-commons/notifications/rep:policy is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/notifications/_rep_policy.xml, nodePath=/etc/acs-commons/notifications/rep:policy, line=3
[ERROR] ValidationViolation: "Node /etc/acs-commons/notifications/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/acs-commons/notifications/_rep_policy.xml, nodePath=/etc/acs-commons/notifications/rep:policy/allow, line=7
[INFO] Ancestor node /etc/cloudservices/dtm is not covered by any of the filter rules. Preferably depend on a package that provides this node!
[ERROR] ValidationViolation: "Node /etc/cloudservices/dtm/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/cloudservices/dtm/_rep_policy.xml, nodePath=/etc/cloudservices/dtm/rep:policy/allow, line=7
[INFO] Ancestor node /etc/cloudservices/sharethis is not covered by any of the filter rules. Preferably depend on a package that provides this node!
[ERROR] ValidationViolation: "Node /etc/cloudservices/sharethis/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/cloudservices/sharethis/_rep_policy.xml, nodePath=/etc/cloudservices/sharethis/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Node /etc/cloudservices/typekit/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/cloudservices/typekit/_rep_policy.xml, nodePath=/etc/cloudservices/typekit/rep:policy/allow, line=7
[INFO] Ancestor node /etc/cloudservices/typekit is not covered by any of the filter rules. Preferably depend on a package that provides this node!
[ERROR] ValidationViolation: "Node /etc/notification/email/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/etc/notification/email/_rep_policy.xml, nodePath=/etc/notification/email/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Node /var/acs-commons/on-deploy-scripts-status/rep:policy is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/on-deploy-scripts-status/_rep_policy.xml, nodePath=/var/acs-commons/on-deploy-scripts-status/rep:policy, line=3
[ERROR] ValidationViolation: "Node /var/acs-commons/on-deploy-scripts-status/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/on-deploy-scripts-status/_rep_policy.xml, nodePath=/var/acs-commons/on-deploy-scripts-status/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Node /var/acs-commons/mcp/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/mcp/_rep_policy.xml, nodePath=/var/acs-commons/mcp/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Node /var/acs-commons/mcp/rep:policy is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/mcp/_rep_policy.xml, nodePath=/var/acs-commons/mcp/rep:policy, line=3
[ERROR] ValidationViolation: "Node /var/acs-commons/httpcache/root is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/httpcache/root/.content.xml, nodePath=/var/acs-commons/httpcache/root, line=3
[ERROR] ValidationViolation: "Node /var/acs-commons/httpcache/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/httpcache/_rep_policy.xml, nodePath=/var/acs-commons/httpcache/rep:policy/allow, line=8
[ERROR] ValidationViolation: "Node /var/acs-commons/httpcache/rep:policy is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/httpcache/_rep_policy.xml, nodePath=/var/acs-commons/httpcache/rep:policy, line=3
[ERROR] ValidationViolation: "Node /var/acs-commons/rep:policy/allow is not contained in any of the filter rules", filePath=jcr_root/var/acs-commons/_rep_policy.xml, nodePath=/var/acs-commons/rep:policy/allow, line=7
[ERROR] ValidationViolation: "Package '/Users/konradwindszus/git/acs-aem-commons/ui.content/target/acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip' contains index definition (maybe in sub packages) but the according property allowIndexDefinitions is not set to 'true'"

One is already tackled in https://issues.apache.org/jira/browse/JCRVLT-343 and all the other ones are contained in https://issues.apache.org/jira/browse/JCRVLT-372

coveralls · 2019-09-17T14:39:48Z

Pull Request Test Coverage Report for Build 5002

0 of 0 changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 54.405%

Totals
Change from base Build 4984:	0.0%
Covered Lines:	14375
Relevant Lines:	26422

💛 - Coveralls

HitmanInWis · 2019-09-17T17:21:49Z

I strongly feel that original PR creators should be credited with their work, no matter how small. I would rather we merge #2032 to give credit to @geertsmichael. Giving credit where due promotes contribution.

kwin · 2019-09-17T17:29:44Z

The PR from #2032 is unfortunately not correct, i.e. it will neither import the readme.txt below /var/acs-commons/on-deploy-scripts-status nor does it fix some other remaining issues. But I will give credits to @geertsmichael by adding a co-authored-by trailer with his email in my commit.

kwin · 2019-09-19T07:01:01Z

Now also all rep:policy nodes are included. I would go ahead and merge this afternoon if there are no objections.

HitmanInWis · 2019-09-19T13:24:52Z

ui.content/src/main/content/META-INF/vault/filter.xml

-        <include
-            pattern="/etc/acs-commons/qr-code/jcr:content/clientlib-author"
-            mode="merge"/>
-        <exclude


Any idea if this was here for a good reason? i.e. does the QR Code tool store configs (set from AEM) under here and are we blowing them away on re-deploy of ACS Commons?

I think indeed the QR code can be toggled (i.e. enabled/disabled). This settings is persisted in /etc/acs-commons/qr-code/jcr:content/config. So I think this part should be added as dedicated filter root with a mode merge. I will work on this.

Should be fixed now

@HitmanInWis this theoretical situation can easily be made into an automated test by an oakpal scan with a forcedRoot of /etc/acs-commons/qr-code/jcr:content/config/oldNode and the basic/paths check.

HitmanInWis · 2019-09-19T13:31:40Z

ui.content/src/main/content/META-INF/vault/filter.xml

@@ -8,6 +8,7 @@
        <include pattern="/etc/acs-commons/automatic-package-replication/jcr:content"/>
        <include pattern="/etc/acs-commons/bulk-workflow-manager"/>
        <include pattern="/etc/acs-commons/bulk-workflow-manager/jcr:content"/>
+        <include pattern="/etc/acs-commons/bulk-workflow-manager/rep:policy(/.*)?"/>


Are we really failing to deploy a ton of rep:policy nodes? I would imagine a ton of things are broken for new installs if that's the case, right? Was this caused by recent changes?

There is a bug in FileVault which might install the rep:policy nodes anyways, but as it has been clarified in https://issues.apache.org/jira/browse/JCRVLT-372 that would rather be a bug. Therefore I took the opportunity to clean things up here.

HitmanInWis · 2019-09-19T13:33:05Z

ui.content/src/main/content/META-INF/vault/filter.xml

-        <include pattern="/etc/acs-commons/instant-package/jcr:content"/>
-        <include pattern="/etc/acs-commons/instant-package/jcr:content/instant-package-image.png"/>
-        <include pattern="/etc/acs-commons/instant-package/jcr:content/config"/>
+        <include pattern="/etc/acs-commons/instant-package/jcr:content(/.*)?"/>


If the tool saves some other nodes (from the AEM UI) under jcr:content will this new config now blow those away?

good point, actually the user change something below /etc/acs-commons/instant-package/jcr:content/config so this path should be covered by a dedicated filter root with mode=merge

Should be fixed now.

@kwin @HitmanInWis this theoretical situation can easily be made into an automated test by an oakpal scan with a forcedRoot of /etc/acs-commons/instant-package/jcr:content/config/oldNode and the basic/paths check.

these forcedRoots probably just needs to be added to the acs-internal.json checklist.

… and config page checking

adamcin · 2019-09-19T18:09:18Z

@kwin I added some oakpal configs to the ui.content package pom to regression test your changes here. They are in PR #2051 .

HitmanInWis · 2019-09-20T13:01:44Z

ui.content/src/main/content/META-INF/vault/filter.xml

        <include pattern="/var/acs-commons/jcr:content"/>
+        <include pattern="/var/acs-commons/mcp/rep:policy(/.*)?"/>


This is not being included - may need to add a filter for /var/acs-commons/mcp

Yes, correct. I am gonna include the parent as well and will try to add a validation check for this.

Resolved in bc14186

HitmanInWis · 2019-09-20T13:11:43Z

ui.content/src/main/content/META-INF/vault/filter.xml

-
+        <include pattern="/etc/acs-commons/instant-package/jcr:content(/.*)?"/>
+        <!-- the user specific configuration should not be touched -->
+        <exclude pattern="/etc/acs-commons/instant-package/jcr:content/config(/.*)?"/>


I placed a node under both /etc/acs-commons/instant-package/jcr:content/config and /etc/acs-commons/qr-code/jcr:content/config and on deploy the nodes were blown away. Am I doing something wrong?

Indeed, that is very weird, seems like a bug in FileVault, let me investigate.
Update: Ok, I reported this before. It is https://issues.apache.org/jira/browse/JCRVLT-255. Let me see if I can find a workaround. The exclude does work correctly but the mode=merge not for the config node.

Resolved bc14186

HitmanInWis · 2019-09-20T16:28:27Z

Thanks for fixing the issues turned up in my testing @kwin - I'll re-test soon. I know stuff like this gets past all of us when developing, and I'm not perfect either, but please be more diligent in testing your PRs and the code they affect. Losing the on-deploy-scripts-status nodes in the first place was from a previous PR of yours as well, and though both the developer and the person merging the PR have responsibility in testing the change the primary responsibility is on the developer submitting the PR.

I appreciate your eagerness to contribute, just want to encourage more comprehensive testing especially when making refactors, as breaking ACS Commons affects developers on real projects that depend on this stuff to "just work".

…#2051) * for #2045 added oakpal config for rep:policy and config page checking

HitmanInWis

Please merge in latest master which includes the new oakpal checks from @adamcin in #2051 and update the check-expected-policy-paths check to do oakpal.majorViolation for missing policies rather than oakpal.minorViolation

HitmanInWis · 2019-09-20T17:03:52Z

Also, since I dont want to lose the commit that @geertsmichael contributed, please squash your additional commits into a single commit so there are only 2 commits to merge (the one with geertsmichael, and the one with your additional stuff) so that I dont have to squash and lose the history (and thus the appropriate accreditation)

kwin · 2019-09-25T14:01:03Z

Done and you can see the co-authoring nicely e.g. in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/2045/commits.

HitmanInWis · 2019-09-25T14:45:25Z

Thanks @kwin can you please merge latest master and update the oakpal check for check-expected-policy-paths per the request above?

Remove invalid merge option on include/exclude elements. This closes Adobe-Consulting-Services#2044 Co-authored-by: Michael Geerts <michael.geerts@ida-mediafoundry.be>

kwin · 2019-09-25T15:12:09Z

Done, but now I see

[INFO] --- oakpal-maven-plugin:1.4.2:verify (oakpal-verify) @ acs-aem-commons-ui.content ---
[INFO] OakPAL Check Reports
[INFO]   com.adobe.acs.acs-aem-commons-oakpal-checks/acs-internal/enforce-no-deletes
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[INFO]   net.adamcin.oakpal.core/basic/paths
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[INFO]   net.adamcin.oakpal.core/basic/paths
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[INFO]   net.adamcin.oakpal.core/basic/paths
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[INFO]   com.adobe.acs.acs-aem-commons-oakpal-checks/acs-internal/enforce-no-deletes
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[INFO]   net.adamcin.oakpal.core/basic/paths
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/instant-package/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR]    +- <MAJOR> deleted path /etc/acs-commons/qr-code/jcr:content/config/default. All deletions are denied. [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]
[ERROR] ** Violations were reported at or above severity: MAJOR **

I don't really know what those are supposed to mean.
@adamcin any idea?

HitmanInWis · 2019-09-25T15:30:13Z

Does that refer to my comment above about how the ACS Commons deploy is now blowing away custom nodes under /etc/acs-commons/instant-package/jcr:content/config and /etc/acs-commons/qr-code/jcr:content/config? If so, this is reporting a true bug - ACS Commons deploy should not blow those away.

kwin · 2019-09-25T15:57:46Z

The nodes are no longer overwritten. To me that looks like a false positive in oakpal-check

adamcin · 2019-09-25T15:59:13Z

@HitmanInWis @kwin correct. those are arbitrary children paths I establish before the scan to detect unintentional deletion of content authored content.

adamcin · 2019-09-25T16:28:27Z

@kwin could be. you can temporarily modify that inlineScript function in the pom to use the session to see if those default nodes still exist even if they registered as deletions.

HitmanInWis · 2019-09-26T13:42:31Z

@kwin I tested this again, and using the latest code from your branch I see the same behavior.

If I create the following nodes:

/etc/acs-commons/instant-package/jcr:content/config/mytest
/etc/acs-commons/qr-code/jcr:content/config/mytest
they are removed on deploy. This is bad, and what OakPAL is reporting.

Technically Im not sure if either of those features put nodes under config, but leaving the filter as-is fundamentally incorrect.

What is a "real" but though is the config node itself is being overwritten. Going to both the QR Code and Instant Package config pages and enabling the features updates the config node for each feature to set the enabled property to true but then re-deploying ACS AEM Commons with your current code changes those enabled properties back to false.

adamcin · 2019-09-26T14:02:19Z

@kwin I pulled your branch locally and iterated a bit on the oakpal check by adding this section to the beginning of the inlineScript element to report the absence of the instant-package path both before package extract and after package extract:

                                function beforeExtract(packageId, session) {
                                    var instantPackagePath = "/etc/acs-commons/instant-package/jcr:content/config/default";
                                    if (!session.itemExists(instantPackagePath)) {
                                        oakpal.majorViolation("expected forced path beforeExtract: " + instantPackagePath, packageId);
                                    }
                                }
                                function afterExtract(packageId, session) {
                                    var instantPackagePath = "/etc/acs-commons/instant-package/jcr:content/config/default";
                                    if (!session.itemExists(instantPackagePath)) {
                                        oakpal.majorViolation("expected forced path afterExtract: " + instantPackagePath, packageId);
                                    }
                                    var policyPaths = [
                                        "/oak:index",
                                        "/content",
                                        "/content/dam",
                                        ...

When I ran this on the existing content, I confirmed that the default node is getting deleted upon install, because only the afterExtract violation was added to the report:

[INFO]   check-expected-policy-paths
[ERROR]    +- <MAJOR> expected forced path afterExtract: /etc/acs-commons/instant-package/jcr:content/config/default [acs-aem-commons-ui.content-4.3.3-SNAPSHOT.zip]

I added explicit primary and mixin node types to the forcedRoot definitions for each parent of the instant-package config default path to be sure that it wasn't a constraint violation preventing retention of the children. (I also had to import the package nodetypes.cnd using <cndNames> to allow using the cq:Page and cq:PageContent nodetypes in the forcedRoots)

                        <forcedRoot>
                            <path>/etc/acs-commons/instant-package</path>
                            <primaryType>cq:Page</primaryType>
                        </forcedRoot>
                        <forcedRoot>
                            <path>/etc/acs-commons/instant-package/jcr:content</path>
                            <primaryType>cq:PageContent</primaryType>
                        </forcedRoot>
                        <forcedRoot>
                            <path>/etc/acs-commons/instant-package/jcr:content/config</path>
                            <primaryType>nt:unstructured</primaryType>
                        </forcedRoot>
                        <forcedRoot>
                            <path>/etc/acs-commons/instant-package/jcr:content/config/default</path>
                            <primaryType>nt:unstructured</primaryType>
                        </forcedRoot>

But defining this extra existing structure did not eliminate the violations from the report.

I've got a hop on a flight right now, so I'll take a look at other possibilities after I land.

kwin · 2019-09-26T15:07:20Z

I can confirm that those nodes still get overwritten. I tried to identify the issue and the exclude does definitely work! But the merge mode on the dedicated filter rule does not work for some reason. Also merge="update" does not work. But once I remove the filter entries for /etc/acs-commons/instant-package/jcr:content/config it starts working. So maybe another filevault bug...

HitmanInWis · 2019-09-26T15:33:21Z

Ok, is there something you can do with the filter.xml in the meantime to work around the issue?

kwin · 2019-09-26T15:44:13Z

I guess one could just leave the node completely out from the filter, but then you will never ever be able to update that via any means in case it is already there (e.g. if there is the wrong resource type being set on that node). WDYT?

HitmanInWis · 2019-09-26T15:46:42Z

Probably should leave the config nodes out of ever updating b/c as of now that's where the enabled property is stored, so allowing for the edge case of wrong resource type to be fixed would cause the normal case of enabling the feature to be overwritten. Basically the config node and its children should only be written if not pre-existing.

badvision · 2019-09-26T15:47:41Z

Probably should leave the config nodes out of ever updating b/c as of now that's where the enabled property is stored, so allowing for the edge case of wrong resource type to be fixed would cause the normal case of enabling the feature to be overwritten. Basically the config node and its children should only be written if not pre-existing.

Makes sense to me -- isn't that what the merge is supposed to do?

adamcin · 2019-09-26T18:46:59Z

@kwin it looks like AEM 6.3 (min supported AEM version of acs-aem-commons 4.0.0+) ships with filevault 3.1.38, which means it might support the matchProperties attribute on the include/exclude elements added with JCRVLT-120 in v3.1.28:

Maybe this can be done with an <include pattern=".*/sling:resourceType" matchProperties="true"/> element or an <exclude pattern=".*/config/enabled" matchProperties="true"/> element?

HitmanInWis · 2019-09-26T21:10:49Z

Let's go with something simple for now to fix the issue and get the branch back to a working state. There are some blocker bugs fixed by this PR so I think we should try to get this merged ASAP.

stale · 2019-11-25T21:37:13Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

badvision · 2019-12-02T15:53:11Z

Is this PR still needed @kwin, @adamcin, @HitmanInWis? Looking at the merge conflicts it seems like we solved the problem in a slightly different way already or am I missing something?

HitmanInWis · 2019-12-02T15:57:54Z

I think this PR had some additional fixes that were not included in other PRs, but given the lack of activity plus the conflicts it might make sense to let this roll off as stale.

kwin · 2019-12-26T11:30:04Z

Unfortunately property excludes do not work correctly due to https://issues.apache.org/jira/browse/JCRVLT-390?jql=project%20%3D%20JCRVLT%20AND%20fixVersion%20%3D%203.4.2. So I really need to investigate why merge does not work correctly in this case.

kwin · 2019-12-26T11:36:46Z

I can confirm that those nodes still get overwritten. I tried to identify the issue and the exclude does definitely work! But the merge mode on the dedicated filter rule does not work for some reason. Also merge="update" does not work.

This is now tracked in https://issues.apache.org/jira/browse/JCRVLT-396

stale · 2020-02-24T11:39:51Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

kwin mentioned this pull request Sep 17, 2019

Fixing /var/acs-commons filter.xml #2032

Merged

kwin force-pushed the bugfix/fix-filter branch from 0f157e5 to c3e3add Compare September 17, 2019 14:33

kwin force-pushed the bugfix/fix-filter branch 2 times, most recently from dc46645 to 82f8169 Compare September 18, 2019 06:46

Ronald-Diemicke previously approved these changes Sep 18, 2019

View reviewed changes

This was referenced Sep 18, 2019

Fixing Issue #2046 - Adding filter items needed for on-deploy-script to function #2047

Closed

/var/acs-commons/on-deploy-scripts-status never gets created #2046

Closed

kwin requested a review from davidjgonzalez September 19, 2019 07:01

kwin dismissed Ronald-Diemicke’s stale review via 5052268 September 19, 2019 07:15

kwin force-pushed the bugfix/fix-filter branch from 82f8169 to 5052268 Compare September 19, 2019 07:15

kwin requested a review from HitmanInWis September 19, 2019 07:39

HitmanInWis reviewed Sep 19, 2019

View reviewed changes

adamcin added a commit to adamcin/acs-aem-commons that referenced this pull request Sep 19, 2019

for Adobe-Consulting-Services#2045 added oakpal config for rep:policy…

81195b1

… and config page checking

HitmanInWis requested changes Sep 20, 2019

View reviewed changes

HitmanInWis pushed a commit that referenced this pull request Sep 20, 2019

for #2045 added oakpal config for rep:policy and config page checking (…

866ee41

…#2051) * for #2045 added oakpal config for rep:policy and config page checking

HitmanInWis requested changes Sep 20, 2019

View reviewed changes

kwin mentioned this pull request Sep 23, 2019

[URL Asset Import] Unable to create node at /var/acs-commons/mcp #2031

Closed

3 tasks

kwin force-pushed the bugfix/fix-filter branch from bc14186 to c4c8a80 Compare September 25, 2019 14:00

Include all nodes in the filter.xml

c54c541

Remove invalid merge option on include/exclude elements. This closes Adobe-Consulting-Services#2044 Co-authored-by: Michael Geerts <michael.geerts@ida-mediafoundry.be>

kwin force-pushed the bugfix/fix-filter branch from c4c8a80 to c54c541 Compare September 25, 2019 15:11

Merge branch 'master' into bugfix/fix-filter

f2bc8cd

stale bot added the wontfix label Nov 25, 2019

stale bot removed the wontfix label Dec 2, 2019

stale bot added the wontfix label Feb 24, 2020

stale bot closed this Mar 3, 2020

		<include pattern="/var/acs-commons/jcr:content"/>
		<include pattern="/var/acs-commons/mcp/rep:policy(/.*)?"/>

Include all nodes in the filter.xml #2045

Include all nodes in the filter.xml #2045

Conversation

kwin commented Sep 17, 2019

update-changelog bot commented Sep 17, 2019

kwin commented Sep 17, 2019

kwin commented Sep 17, 2019

coveralls commented Sep 17, 2019 • edited Loading

Pull Request Test Coverage Report for Build 5002

💛 - Coveralls

HitmanInWis commented Sep 17, 2019

kwin commented Sep 17, 2019 • edited Loading

kwin commented Sep 19, 2019

Choose a reason for hiding this comment

kwin Sep 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwin Sep 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamcin commented Sep 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwin Sep 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HitmanInWis commented Sep 20, 2019

HitmanInWis left a comment

Choose a reason for hiding this comment

HitmanInWis commented Sep 20, 2019

kwin commented Sep 25, 2019

HitmanInWis commented Sep 25, 2019

kwin commented Sep 25, 2019

HitmanInWis commented Sep 25, 2019

kwin commented Sep 25, 2019

adamcin commented Sep 25, 2019

adamcin commented Sep 25, 2019

HitmanInWis commented Sep 26, 2019

adamcin commented Sep 26, 2019

kwin commented Sep 26, 2019

HitmanInWis commented Sep 26, 2019

kwin commented Sep 26, 2019

HitmanInWis commented Sep 26, 2019

badvision commented Sep 26, 2019

adamcin commented Sep 26, 2019

HitmanInWis commented Sep 26, 2019

stale bot commented Nov 25, 2019

badvision commented Dec 2, 2019

HitmanInWis commented Dec 2, 2019

kwin commented Dec 26, 2019

kwin commented Dec 26, 2019

stale bot commented Feb 24, 2020

coveralls commented Sep 17, 2019 •

edited

Loading

kwin commented Sep 17, 2019 •

edited

Loading

kwin Sep 19, 2019 •

edited

Loading

kwin Sep 19, 2019 •

edited

Loading

adamcin commented Sep 19, 2019 •

edited

Loading

kwin Sep 20, 2019 •

edited

Loading