[jira] [Commented] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862756#comment-17862756
]
Kevan Jahanshahi commented on JCR-5076:
---
Thanks a lot [~reschke]
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
> Fix For: 2.24, 2.23.0
>
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862734#comment-17862734
]
Julian Reschke edited comment on JCR-5076 at 7/3/24 11:18 AM:
--
Thanks, [~jkevan]. Backports will happen eventually as per our usual procedure
(cascading after releasing from the upper branch).
was (Author: reschke):
Thanks, [~jkevan]. Backports will happen eventually.
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
> Fix For: 2.24, 2.23.0
>
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862733#comment-17862733
]
Julian Reschke commented on JCR-5076:
-
trunk:
[6313b0502|https://github.com/apache/jackrabbit/commit/6313b0502a13c623410e95dc918ba84558b3531a]
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
> Fix For: 2.24, 2.23.0
>
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862734#comment-17862734
]
Julian Reschke commented on JCR-5076:
-
Thanks, [~jkevan]. Backports will happen eventually.
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
> Fix For: 2.24, 2.23.0
>
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved JCR-5076.
-
Fix Version/s: 2.24
2.23.0
Resolution: Fixed
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
> Fix For: 2.24, 2.23.0
>
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-5076:
Labels: candidate_jackrabbit_2.20 candidate_jackrabbit_2.22 (was: )
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_jackrabbit_2.20, candidate_jackrabbit_2.22
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Jahanshahi updated JCR-5076:
--
Description:
In *jackrabbit-aws-ext* subproject there is a dependency:
{code:java}
org.apache.jackrabbit
jackrabbit-data
${project.version}
test-jar
{code}
I think it should be:
{code:java}
test {code}
Would be great if it's possible to backport this fix to previous versions
(2.21.x, 2.20.x) but I let you decided about it, depending on your release
schedule and maintained versions.
Here is a pull request with the small fix:
[https://github.com/apache/jackrabbit/pull/194]
was:
In *jackrabbit-aws-ext* subproject there is a dependency:
{code:java}
org.apache.jackrabbit
jackrabbit-data
${project.version}
test-jar
{code}
I think it should be:
{code:java}
test {code}
Would be great if it's possible to backport this fix to previous versions
(2.21.x, 2.20.x) but I let you decided about it, depending on your release
schedule and maintained versions.
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
> Here is a pull request with the small fix:
> [https://github.com/apache/jackrabbit/pull/194]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned JCR-5076:
---
Assignee: Julian Reschke
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Assignee: Julian Reschke
>Priority: Trivial
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
[
https://issues.apache.org/jira/browse/JCR-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Jahanshahi updated JCR-5076:
--
Description:
In *jackrabbit-aws-ext* subproject there is a dependency:
{code:java}
org.apache.jackrabbit
jackrabbit-data
${project.version}
test-jar
{code}
I think it should be:
{code:java}
test {code}
Would be great if it's possible to backport this fix to previous versions
(2.21.x, 2.20.x) but I let you decided about it, depending on your release
schedule and maintained versions.
was:
In *jackrabbit-aws-ext* subproject there is a dependency:
{code:java}
org.apache.jackrabbit
jackrabbit-data
${project.version}
test-jar
{code}
I think it should be:
{code:java}
test {code}
> Use correctly test scope for dependencies of type: test-jar
> ---
>
> Key: JCR-5076
> URL: https://issues.apache.org/jira/browse/JCR-5076
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-aws-ext
>Affects Versions: 2.20.16, 2.21.27, 2.22.0
>Reporter: Kevan Jahanshahi
>Priority: Trivial
>
> In *jackrabbit-aws-ext* subproject there is a dependency:
> {code:java}
>
> org.apache.jackrabbit
> jackrabbit-data
> ${project.version}
> test-jar
> {code}
> I think it should be:
> {code:java}
> test {code}
> Would be great if it's possible to backport this fix to previous versions
> (2.21.x, 2.20.x) but I let you decided about it, depending on your release
> schedule and maintained versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCR-5076) Use correctly test scope for dependencies of type: test-jar
Kevan Jahanshahi created JCR-5076:
-
Summary: Use correctly test scope for dependencies of type:
test-jar
Key: JCR-5076
URL: https://issues.apache.org/jira/browse/JCR-5076
Project: Jackrabbit Content Repository
Issue Type: Task
Components: jackrabbit-aws-ext
Affects Versions: 2.22.0, 2.21.27, 2.20.16
Reporter: Kevan Jahanshahi
In *jackrabbit-aws-ext* subproject there is a dependency:
{code:java}
org.apache.jackrabbit
jackrabbit-data
${project.version}
test-jar
{code}
I think it should be:
{code:java}
test {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCR-4892) support the jakarta.servlet package name
[
https://issues.apache.org/jira/browse/JCR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862441#comment-17862441
]
Julian Reschke edited comment on JCR-4892 at 7/2/24 1:19 PM:
-
Did you try with "-PintegrationTesting"?
I see:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 25.36 s
<<< FAILURE! -- in org.apache.jackrabbit.j2ee.TomcatIT
[ERROR] org.apache.jackrabbit.j2ee.TomcatIT.testTomcat -- Time elapsed: 25.18 s
<<< FAILURE!
junit.framework.ComparisonFailure: expected: but
was:
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:260)
at org.apache.jackrabbit.j2ee.TomcatIT.testTomcat(TomcatIT.java:138)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at junit.framework.TestCase.runTest(TestCase.java:177)
at junit.framework.TestCase.runBare(TestCase.java:142)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
{noformat}
was (Author: reschke):
Did you try with "-PintegrationTesting"?
I see:
{noformat}
(...)
{noformat}
> support the jakarta.servlet package name
>
>
> Key: JCR-4892
> URL: https://issues.apache.org/jira/browse/JCR-4892
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 2.24
>
> Attachments: JCR-4892_v2_project_root.patch,
> JCR-4892_v2_workspace_root.patch, JCR-4892_v3.patch, JCR-4892_v4.patch, clean
> install-Output.txt, jackrabbit-webdav-jakarta.patch, patch.txt, webapp.patch,
> webapp2.patch
>
>
> ...without breaking existing uses for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved JCRVLT-747.
---
Fix Version/s: 3.7.4
Resolution: Fixed
> Import of authorizable nodes appears not to process "{BinaryRef}" property
> values
> -
>
> Key: JCRVLT-747
> URL: https://issues.apache.org/jira/browse/JCRVLT-747
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 3.7.4
>
>
> It appears that import of authorizable nodes will not process binary
> properties using the '\{BinaryRef}' format. Instead, their values are passed
> to the JCR's XML import handler, which then complains about the value not
> being base64-encoded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4892) support the jakarta.servlet package name
[
https://issues.apache.org/jira/browse/JCR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862441#comment-17862441
]
Julian Reschke commented on JCR-4892:
-
Did you try with "-PintegrationTesting"?
I see:
{noformat}
(...)
{noformat}
> support the jakarta.servlet package name
>
>
> Key: JCR-4892
> URL: https://issues.apache.org/jira/browse/JCR-4892
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 2.24
>
> Attachments: JCR-4892_v2_project_root.patch,
> JCR-4892_v2_workspace_root.patch, JCR-4892_v3.patch, JCR-4892_v4.patch, clean
> install-Output.txt, jackrabbit-webdav-jakarta.patch, patch.txt, webapp.patch,
> webapp2.patch
>
>
> ...without breaking existing uses for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861157#comment-17861157
]
Julian Reschke edited comment on JCRVLT-747 at 7/1/24 1:34 PM:
---
PR updated and ready for review (the problem I was facing previously was that I
did not take recursion into account).
was (Author: reschke):
PR updated and ready for review (the problem I was facing previously was that I
did not take recursiion into account).
> Import of authorizable nodes appears not to process "{BinaryRef}" property
> values
> -
>
> Key: JCRVLT-747
> URL: https://issues.apache.org/jira/browse/JCRVLT-747
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> It appears that import of authorizable nodes will not process binary
> properties using the '\{BinaryRef}' format. Instead, their values are passed
> to the JCR's XML import handler, which then complains about the value not
> being base64-encoded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861157#comment-17861157
]
Julian Reschke commented on JCRVLT-747:
---
PR updated and ready for review (the problem I was facing previously was that I
did not take recursiion into account).
> Import of authorizable nodes appears not to process "{BinaryRef}" property
> values
> -
>
> Key: JCRVLT-747
> URL: https://issues.apache.org/jira/browse/JCRVLT-747
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> It appears that import of authorizable nodes will not process binary
> properties using the '\{BinaryRef}' format. Instead, their values are passed
> to the JCR's XML import handler, which then complains about the value not
> being base64-encoded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856773#comment-17856773
]
Julian Reschke commented on JCRVLT-747:
---
OK; I believe I have confirmed my theory -- added an "early fail" into
JcrSysViewTransformer (see PR).
Now the question is: can we handle that, like:
a) replace reference properties by empty binaries inside "startNode" (that
seems to work)
b) collect the skipped properties for setting in a later step? (that's what I
couldn't get working yet, would we do that in "endNode"?)
> Import of authorizable nodes appears not to process "{BinaryRef}" property
> values
> -
>
> Key: JCRVLT-747
> URL: https://issues.apache.org/jira/browse/JCRVLT-747
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> It appears that import of authorizable nodes will not process binary
> properties using the '\{BinaryRef}' format. Instead, their values are passed
> to the JCR's XML import handler, which then complains about the value not
> being base64-encoded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856516#comment-17856516
]
Julian Reschke commented on JCRVLT-747:
---
So, as far as I understand:
- JcrSysViewTransformer is used for authorizables
(https://github.com/apache/jackrabbit-filevault/blob/a6f3ccf2d2728265fb50e62ed41e39dc5649d7c8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L754)
- that transformer is used to feed data into JCR's sysview import
- but that does not support binary references (by definition)
If this is the case, it might be possible to pass in an empty binary, do the
import, and then "patch" it with the binaryref value once created.
> Import of authorizable nodes appears not to process "{BinaryRef}" property
> values
> -
>
> Key: JCRVLT-747
> URL: https://issues.apache.org/jira/browse/JCRVLT-747
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> It appears that import of authorizable nodes will not process binary
> properties using the '\{BinaryRef}' format. Instead, their values are passed
> to the JCR's XML import handler, which then complains about the value not
> being base64-encoded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-747) Import of authorizable nodes appears not to process "{BinaryRef}" property values
[
https://issues.apache.org/jira/browse/JCRVLT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825367#comment-17825367
]
Julian Reschke edited comment on JCRVLT-747 at 6/20/24 1:26 PM:
Ok, I *believe* I have a test (ugly). See
https://github.com/apache/jackrabbit-filevault/pull/333
To run:
{noformat}
mvn clean install -Dit.test=BinaryPropertiesIT
{noformat}
Result:
{noformat}
16:53:18.286 [main] ERROR o.a.j.v.p.impl.ZipVaultPackage - Error during install.
javax.jcr.RepositoryException:
org.apache.jackrabbit.vault.fs.io.DocViewParser$XmlParseException: specified
data is not base64 encoded
at
org.apache.jackrabbit.vault.fs.impl.io.AbstractArtifactHandler.importDocView(AbstractArtifactHandler.java:187)
at
org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:88)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1115)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531)
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:284)
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:168)
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:175)
at
org.apache.jackrabbit.vault.packaging.integration.BinaryPropertiesIT.exportBinary(BinaryPropertiesIT.java:246)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-754: --- Fix Version/s: package-maven-plugin-1.4.0 > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4, package-maven-plugin-1.4.0 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Fix Version/s: package-maven-plugin-1.3.8 Resolution: Fixed Status: Resolved (was: Patch Available) Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/ce96b353906fcaa017e5a92c85186e9e9a7c7c49. > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.8 > > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Assignee: Konrad Windszus Status: Patch Available (was: Open) > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-754: --- Resolution: Fixed Status: Resolved (was: Patch Available) > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855627#comment-17855627 ] Konrad Windszus commented on JCRVLT-754: Applied (without the typo) in r69811. > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855540#comment-17855540 ] Julian Reschke commented on JCRVLT-754: --- Works for me (but note you have a typo: "DvEPENDENCIES"). > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-754: --- Status: Patch Available (was: In Progress) > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855248#comment-17855248 ] Konrad Windszus commented on JCRVLT-754: I attached my proposed fix in [^JCRVLT-754-1.patch]. Please have a look [~reschke]. > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-754: --- Attachment: JCRVLT-754-1.patch > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > Attachments: JCRVLT-754-1.patch > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855246#comment-17855246
]
Konrad Windszus commented on JCRVLT-754:
bq. For the basenames, can we switch it for filevault maintenance releases as
well,
Yes, although it is unlikely to happen. Therefore supporting both ZIP filename
formats is IMHO too much effort
I am not sure about the intent of of the additional check of the SHA1 given as
parameter. There is already a check if the checksums are correctly calculated
for the to-be release source ZIP. What exactly do we want to verify here? Check
if someone replaced the source ZIP and the checksums in the SVN repo as well
as modified the Git tag after the vote has been sent out? Not sure this is
worth checking at all. I would rather tend to make this additional SHA CLI
argument for {{check-release.sh}} optional and leave it out for FileVault. WDYT
[~reschke]?
> check-release does not work for filevault anymore
> -
>
> Key: JCRVLT-754
> URL: https://issues.apache.org/jira/browse/JCRVLT-754
> Project: Jackrabbit FileVault
> Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4
>
>
> Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated
> anymore; however, this is what is put into the generated vote template.
> The proper fix likely would be to put the SHA512 checksum into the vote
> template.
> Furthermore, the basename of the source artefact changed from"src" to
> "source-release". This needs to be adjusted in the check script.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCRVLT-759) Update to ASF Parent POM 32
[ https://issues.apache.org/jira/browse/JCRVLT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-759. Resolution: Fixed > Update to ASF Parent POM 32 > --- > > Key: JCRVLT-759 > URL: https://issues.apache.org/jira/browse/JCRVLT-759 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Affects Versions: 3.7.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-758) validate-files should consider filtered files
[
https://issues.apache.org/jira/browse/JCRVLT-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855110#comment-17855110
]
Konrad Windszus commented on JCRVLT-758:
Maybe there should be some kind of plugin concept for interpolation post
processors. Other use cases apart from FileVault Escaping would probably be
encrypt in a way compatible with [AEM's
CryptoSupport|https://developer.adobe.com/experience-manager/reference-materials/6-5/javadoc/com/adobe/granite/crypto/CryptoSupport.html]
> validate-files should consider filtered files
> -
>
> Key: JCRVLT-758
> URL: https://issues.apache.org/jira/browse/JCRVLT-758
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the goal
> [validate-files|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#filevault-package-validate-files]
> acts on top of the unprocessed source files. In order to enhance the
> validation quality it should take into account the
> [filtering|https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html].
> One reason for this is that filtering sometimes applies invalid docview xml
> attribute values (for example ones containing unescaped {{&}} or {{<}}) which
> are only caught in the filtered file validation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCR-5072) Release Jackrabbit 2.22.0
[ https://issues.apache.org/jira/browse/JCR-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed JCR-5072. --- > Release Jackrabbit 2.22.0 > - > > Key: JCR-5072 > URL: https://issues.apache.org/jira/browse/JCR-5072 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5072) Release Jackrabbit 2.22.0
[ https://issues.apache.org/jira/browse/JCR-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5072. - Resolution: Fixed > Release Jackrabbit 2.22.0 > - > > Key: JCR-5072 > URL: https://issues.apache.org/jira/browse/JCR-5072 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5075) set baseline comparisonVersion to latest stable (2.22.0)
[ https://issues.apache.org/jira/browse/JCR-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5075. - Fix Version/s: 2.23.0 Resolution: Fixed > set baseline comparisonVersion to latest stable (2.22.0) > > > Key: JCR-5075 > URL: https://issues.apache.org/jira/browse/JCR-5075 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.24, 2.23.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5075) set baseline comparisonVersion to latest stable (2.22.0)
[ https://issues.apache.org/jira/browse/JCR-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855087#comment-17855087 ] Julian Reschke commented on JCR-5075: - trunk: [b7a84c819|https://github.com/apache/jackrabbit/commit/b7a84c819d922044c5658e087510a62de9733f40] > set baseline comparisonVersion to latest stable (2.22.0) > > > Key: JCR-5075 > URL: https://issues.apache.org/jira/browse/JCR-5075 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.24, 2.23.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5075) set baseline comparisonVersion to latest stable (2.22.0)
Julian Reschke created JCR-5075: --- Summary: set baseline comparisonVersion to latest stable (2.22.0) Key: JCR-5075 URL: https://issues.apache.org/jira/browse/JCR-5075 Project: Jackrabbit Content Repository Issue Type: Task Components: parent Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 2.22, 2.21.27, 2.22.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5075) set baseline comparisonVersion to latest stable (2.22.0)
[ https://issues.apache.org/jira/browse/JCR-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-5075: Fix Version/s: 2.24 (was: 2.22) (was: 2.21.27) (was: 2.22.0) > set baseline comparisonVersion to latest stable (2.22.0) > > > Key: JCR-5075 > URL: https://issues.apache.org/jira/browse/JCR-5075 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 2.24 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5074) Logging for constraint violations (UUID already exists)
[ https://issues.apache.org/jira/browse/JCR-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855047#comment-17855047 ] Julian Reschke commented on JCR-5074: - That ticket should be for "OAK", right? > Logging for constraint violations (UUID already exists) > --- > > Key: JCR-5074 > URL: https://issues.apache.org/jira/browse/JCR-5074 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Ionut Pirlogea >Priority: Trivial > > In cases where we notice a "uuid already exists" constraint violation - > something that eg can happen in Content Backflow reimporting the same content > which was previously semi-imported - we should increment a metric and ensure > we log the required information (unless the latter is already done through > the current exception - but even then we might want to add perhaps an > additional, explicit log about just the encounter, > independent-of/in-addition-to the exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5074) Logging for constraint violations (UUID already exists)
Ionut Pirlogea created JCR-5074: --- Summary: Logging for constraint violations (UUID already exists) Key: JCR-5074 URL: https://issues.apache.org/jira/browse/JCR-5074 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Ionut Pirlogea In cases where we notice a "uuid already exists" constraint violation - something that eg can happen in Content Backflow reimporting the same content which was previously semi-imported - we should increment a metric and ensure we log the required information (unless the latter is already done through the current exception - but even then we might want to add perhaps an additional, explicit log about just the encounter, independent-of/in-addition-to the exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-759) Update to ASF Parent POM 32
Konrad Windszus created JCRVLT-759: -- Summary: Update to ASF Parent POM 32 Key: JCRVLT-759 URL: https://issues.apache.org/jira/browse/JCRVLT-759 Project: Jackrabbit FileVault Issue Type: Improvement Components: Misc Affects Versions: 3.7.2 Reporter: Konrad Windszus -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-759) Update to ASF Parent POM 32
[ https://issues.apache.org/jira/browse/JCRVLT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-759: -- Assignee: Konrad Windszus > Update to ASF Parent POM 32 > --- > > Key: JCRVLT-759 > URL: https://issues.apache.org/jira/browse/JCRVLT-759 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Affects Versions: 3.7.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-759) Update to ASF Parent POM 32
[ https://issues.apache.org/jira/browse/JCRVLT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-759: --- Fix Version/s: 3.7.4 > Update to ASF Parent POM 32 > --- > > Key: JCRVLT-759 > URL: https://issues.apache.org/jira/browse/JCRVLT-759 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Affects Versions: 3.7.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-758) validate-files should consider filtered files
[
https://issues.apache.org/jira/browse/JCRVLT-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-758:
---
Description:
Currently the goal
[validate-files|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#filevault-package-validate-files]
acts on top of the unprocessed source files. In order to enhance the
validation quality it should take into account the
[filtering|https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html].
One reason for this is that filtering sometimes applies invalid docview xml
attribute values (for example ones containing unescaped {{&}} or {{<}}) which
are only caught in the filtered file validation.
was:
Currently the goal
[validate-files|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#filevault-package-validate-files]
acts on top of the unprocessed source files. In order to enhance the
validation quality it should take into account the
[filtering|https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html].
One reason for this is that filtering sometimes applies invalid docview xml
attribute values which are only caught in the filtered file validation.
> validate-files should consider filtered files
> -
>
> Key: JCRVLT-758
> URL: https://issues.apache.org/jira/browse/JCRVLT-758
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the goal
> [validate-files|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#filevault-package-validate-files]
> acts on top of the unprocessed source files. In order to enhance the
> validation quality it should take into account the
> [filtering|https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html].
> One reason for this is that filtering sometimes applies invalid docview xml
> attribute values (for example ones containing unescaped {{&}} or {{<}}) which
> are only caught in the filtered file validation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-758) validate-files should consider filtered files
Konrad Windszus created JCRVLT-758: -- Summary: validate-files should consider filtered files Key: JCRVLT-758 URL: https://issues.apache.org/jira/browse/JCRVLT-758 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Reporter: Konrad Windszus Currently the goal [validate-files|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#filevault-package-validate-files] acts on top of the unprocessed source files. In order to enhance the validation quality it should take into account the [filtering|https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html]. One reason for this is that filtering sometimes applies invalid docview xml attribute values which are only caught in the filtered file validation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[
https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507
]
Konrad Windszus edited comment on JCRVLT-757 at 6/12/24 6:24 PM:
-
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator. Additional FilterWrappers can be added
via the {{MavenResourcesExecution}}. All wrappers are applied in a nested
fashion (with the default ones being applied last).
was (Author: kwin):
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator.
> Optionally apply Enhanced DocView XML escaping to filtered values
> -
>
> Key: JCRVLT-757
> URL: https://issues.apache.org/jira/browse/JCRVLT-757
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Priority: Major
>
> The filtering option outlined in
> https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html
> currently only supports as-is replacements, i.e. the values are taken
> unprocessed. In order to use the same variable values for different contexts
> it would be nice to optionally apply [FileVault DocView XML
> Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507 ] Konrad Windszus commented on JCRVLT-757: This can be implemented as `org.codehaus.plexus.interpolation.InterpolationPostProcessor` being added to the `FilterWrapper`s interpolator. > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[
https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507
]
Konrad Windszus edited comment on JCRVLT-757 at 6/12/24 5:57 PM:
-
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator.
was (Author: kwin):
This can be implemented as
`org.codehaus.plexus.interpolation.InterpolationPostProcessor` being added to
the `FilterWrapper`s interpolator.
> Optionally apply Enhanced DocView XML escaping to filtered values
> -
>
> Key: JCRVLT-757
> URL: https://issues.apache.org/jira/browse/JCRVLT-757
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Priority: Major
>
> The filtering option outlined in
> https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html
> currently only supports as-is replacements, i.e. the values are taken
> unprocessed. In order to use the same variable values for different contexts
> it would be nice to optionally apply [FileVault DocView XML
> Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Description: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same variable values for different contexts it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] (was: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same property values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]) > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Description: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same property values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] (was: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]) > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same property values for different context > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
Konrad Windszus created JCRVLT-757: -- Summary: Optionally apply Enhanced DocView XML escaping to filtered values Key: JCRVLT-757 URL: https://issues.apache.org/jira/browse/JCRVLT-757 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Affects Versions: package-maven-plugin-1.3.6 Reporter: Konrad Windszus The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed JCR-5067. --- > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854013#comment-17854013 ] Julian Reschke commented on JCR-5067: - Site update: https://github.com/apache/jackrabbit-site/commit/f78ee720058bc44a1186c4da308ffeed06dad6cc Downloads page will be updated when 2.22.0 is released. > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5067. - Resolution: Fixed > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5073) core: avoid varargs related compiler warnings in tests
[ https://issues.apache.org/jira/browse/JCR-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853690#comment-17853690 ] Julian Reschke commented on JCR-5073: - trunk: [7f9888f69|https://github.com/apache/jackrabbit/commit/7f9888f69d6340c9d2da1cec9f4a9b50ef15603b] > core: avoid varargs related compiler warnings in tests > -- > > Key: JCR-5073 > URL: https://issues.apache.org/jira/browse/JCR-5073 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_jackrabbit_2.22 > Fix For: 2.24, 2.23.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5073) core: avoid varargs related compiler warnings in tests
[ https://issues.apache.org/jira/browse/JCR-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-5073: Labels: candidate_jackrabbit_2.22 (was: ) > core: avoid varargs related compiler warnings in tests > -- > > Key: JCR-5073 > URL: https://issues.apache.org/jira/browse/JCR-5073 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Priority: Trivial > Labels: candidate_jackrabbit_2.22 > Fix For: 2.24 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5073) core: avoid varargs related compiler warnings in tests
[ https://issues.apache.org/jira/browse/JCR-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5073. - Fix Version/s: 2.23.0 Assignee: Julian Reschke Resolution: Fixed > core: avoid varargs related compiler warnings in tests > -- > > Key: JCR-5073 > URL: https://issues.apache.org/jira/browse/JCR-5073 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_jackrabbit_2.22 > Fix For: 2.24, 2.23.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5073) core: avoid varargs related compiler warnings in tests
[ https://issues.apache.org/jira/browse/JCR-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-5073: Fix Version/s: 2.24 > core: avoid varargs related compiler warnings in tests > -- > > Key: JCR-5073 > URL: https://issues.apache.org/jira/browse/JCR-5073 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: core >Reporter: Julian Reschke >Priority: Trivial > Fix For: 2.24 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5073) core: avoid varargs related compiler warnings in tests
Julian Reschke created JCR-5073: --- Summary: core: avoid varargs related compiler warnings in tests Key: JCR-5073 URL: https://issues.apache.org/jira/browse/JCR-5073 Project: Jackrabbit Content Repository Issue Type: Task Components: core Reporter: Julian Reschke -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853663#comment-17853663 ] Julian Reschke commented on JCRVLT-755: --- Aha, I see. [~cschneider] - so do you actually see a *removal* of "test4"? > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853661#comment-17853661 ] Konrad Windszus commented on JCRVLT-755: bq. In that case I'd expect it to be replaced by an empty node. Konrad Windszus - would you agree? No, as outlined in https://jackrabbit.apache.org/filevault/docview.html#Empty_Elements. > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853644#comment-17853644 ] Julian Reschke commented on JCRVLT-755: --- In that case I'd expect it to be replaced by an empty node. [~kwin] - would you agree? > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853634#comment-17853634 ] Julian Reschke edited comment on JCRVLT-755 at 6/10/24 12:33 PM: - In both ZIPs I see "test4" as empty node. What is the import mode? REPLACE? UPDATE? What does happen with "test4". Is it *deleted*, or replaced by an empty node? was (Author: reschke): In both ZIPs I see "test4" as empty node. What is the import mode? REPLACE? UPDATE? What does happen woth "test4". Is it *deleted*, or replaced by an empty node? > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853643#comment-17853643 ] Christian Schneider commented on JCRVLT-755: Import mode is replace. As far as I can tell the node is deleted. > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853634#comment-17853634 ] Julian Reschke commented on JCRVLT-755: --- In both ZIPs I see "test4" as empty node. What is the import mode? REPLACE? UPDATE? What does happen woth "test4". Is it *deleted*, or replaced by an empty node? > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4892) support the jakarta.servlet package name
[ https://issues.apache.org/jira/browse/JCR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4892: Fix Version/s: 2.24 > support the jakarta.servlet package name > > > Key: JCR-4892 > URL: https://issues.apache.org/jira/browse/JCR-4892 > Project: Jackrabbit Content Repository > Issue Type: New Feature >Reporter: Julian Reschke >Priority: Major > Fix For: 2.24 > > Attachments: JCR-4892_v2_project_root.patch, > JCR-4892_v2_workspace_root.patch, JCR-4892_v3.patch, JCR-4892_v4.patch, clean > install-Output.txt, jackrabbit-webdav-jakarta.patch, patch.txt, webapp.patch, > webapp2.patch > > > ...without breaking existing uses for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-3943) [jackrabbi-aws-ext] Data inconsistency due to race condition during async uploads
[
https://issues.apache.org/jira/browse/JCR-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3943:
Fix Version/s: (was: 2.22)
(was: 2.22.0)
> [jackrabbi-aws-ext] Data inconsistency due to race condition during async
> uploads
> -
>
> Key: JCR-3943
> URL: https://issues.apache.org/jira/browse/JCR-3943
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Attachments: coredata14Nov5Dec.txt
>
>
> There is a race condition when {{LocalCache}} is used where if an upload
> ({{file_u}}) has entered the cache but not the {{AsyncUploadCache}} and a
> simultaneous PurgeJob is running, then the uploaded file {{file_u}} can be
> purged from the cache.
> When the async job ultimately runs it fails silently (S3 client fails to
> calculate the hash because of the missing file), thus leaving dangling
> references in the node store as well as the {{AsyncUploadCache}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853571#comment-17853571 ] Christian Schneider commented on JCRVLT-755: [~kwin] [~julian.resc...@gmx.de] I am looking for someone who can explain the difference in the two generated packages and how that might explain the different behaviour when applying the package. Can one of you help here? > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4892) support the jakarta.servlet package name
[ https://issues.apache.org/jira/browse/JCR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853515#comment-17853515 ] Jesper Steen Møller edited comment on JCR-4892 at 6/9/24 5:12 PM: -- I [refreshed|[https://github.com/jespersm/jackrabbit/tree/JCR-4892]] this fine patch against current trunk, and opened a [PR|[https://github.com/apache/jackrabbit/pull/191/commits]] against it. Tests run. Since Jackrabbit is now on Java 11 minimum, above issues should be addressed, right? It would be nice to have this in, for support in Spring Boot 3.x. was (Author: jespersm): I refreshed this fine patch against current trunk, and opened a PR against it. Tests run. Since Jackrabbit is now on Java 11 minimum, above issues should be addressed, right? It would be nice to have this in, for support in Spring Boot 3.x. > support the jakarta.servlet package name > > > Key: JCR-4892 > URL: https://issues.apache.org/jira/browse/JCR-4892 > Project: Jackrabbit Content Repository > Issue Type: New Feature >Reporter: Julian Reschke >Priority: Major > Attachments: JCR-4892_v2_project_root.patch, > JCR-4892_v2_workspace_root.patch, JCR-4892_v3.patch, JCR-4892_v4.patch, clean > install-Output.txt, jackrabbit-webdav-jakarta.patch, patch.txt, webapp.patch, > webapp2.patch > > > ...without breaking existing uses for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4892) support the jakarta.servlet package name
[ https://issues.apache.org/jira/browse/JCR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853515#comment-17853515 ] Jesper Steen Møller commented on JCR-4892: -- I refreshed this fine patch against current trunk, and opened a PR against it. Tests run. Since Jackrabbit is now on Java 11 minimum, above issues should be addressed, right? It would be nice to have this in, for support in Spring Boot 3.x. > support the jakarta.servlet package name > > > Key: JCR-4892 > URL: https://issues.apache.org/jira/browse/JCR-4892 > Project: Jackrabbit Content Repository > Issue Type: New Feature >Reporter: Julian Reschke >Priority: Major > Attachments: JCR-4892_v2_project_root.patch, > JCR-4892_v2_workspace_root.patch, JCR-4892_v3.patch, JCR-4892_v4.patch, clean > install-Output.txt, jackrabbit-webdav-jakarta.patch, patch.txt, webapp.patch, > webapp2.patch > > > ...without breaking existing uses for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853381#comment-17853381 ] Stefan Seifert commented on JCRVLT-756: --- thanks for the quick reaction [~bisswanger] , i can confirm the problem is solved in SDK release! > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853138#comment-17853138 ] Ramon Bisswanger commented on JCRVLT-756: - [~sseifert] : a new SDK was released 16647. You can download it from Software Distribution and package installation should work again > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated JCRVLT-755: --- Description: We have a strange issue where replication of a folder deletes all contents of the folder on destination system. We create a filevault package from the folder and apply the package using filevault on the destination system. It seems the behaviour is different depending if the folder or parent folder has a jcr:content sub node. I attached two content packages: * working.zip : Export of /content/experience-fragements/test2 when experience-fragements has jcr:content subnode. In this case an existing experience fragement at /content/experience-fragements/test2/test4 is not deleted * deleted.zip : Export of /content/experience-fragements/test2 when experience-fragements does not have jcr:content subnode. In this case prio existing test4 content fragment was deletedon apply. The content packages look different. In the case with jcr:content experience-fragments and test2 are folders in the zip. In case without jcr:content inside experience-fragments there are no folders like above. Instead the sub nodes are inside a single content.xml was: We have a strange issue where replication of a folder deletes all contents of the folder on destination system. We create a filevault package from the folder and apply the package using filevault on the destination system. It seems the behaviour is different depending if the folder or parent folder has a jcr:content sub node. I will provide one sample package where the issue occurs and one where the issue does not occur. > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated JCRVLT-755: --- Attachment: deleted.zip working.zip > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I will provide one sample package where the issue occurs and one where the > issue does not occur. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-756. Resolution: Invalid > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853041#comment-17853041 ] Julian Reschke commented on JCR-5067: - trunk: [65cdc6769|https://github.com/apache/jackrabbit/commit/65cdc6769b56c09d5b40f49c91191771a6e93a00] 2.22: [f7c4ac8af|https://github.com/apache/jackrabbit/commit/f7c4ac8afaac88addd6185b8b5ed8667a703c59b] [cdc9cf442|https://github.com/apache/jackrabbit/commit/cdc9cf442e5002461494cd94bfd637d442b96a3e] > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5050) Release Jackrabbit 2.20.16
[ https://issues.apache.org/jira/browse/JCR-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5050. - Resolution: Fixed > Release Jackrabbit 2.20.16 > -- > > Key: JCR-5050 > URL: https://issues.apache.org/jira/browse/JCR-5050 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCR-5050) Release Jackrabbit 2.20.16
[ https://issues.apache.org/jira/browse/JCR-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed JCR-5050. --- > Release Jackrabbit 2.20.16 > -- > > Key: JCR-5050 > URL: https://issues.apache.org/jira/browse/JCR-5050 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5072) Release Jackrabbit 2.22.0
Julian Reschke created JCR-5072: --- Summary: Release Jackrabbit 2.22.0 Key: JCR-5072 URL: https://issues.apache.org/jira/browse/JCR-5072 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853032#comment-17853032 ] Ramon Bisswanger commented on JCRVLT-756: - [~sseifert] : the issue indeed is not on FileVault. We were able to confirm a SDK-only regression on Adobe-side in the 16544 SDK. Working on a fix for that, but I guess this SLING ticket can be closed as the fix won't involve any changes on Apache components. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853019#comment-17853019 ] Julian Reschke commented on JCR-5067: - Left to do: - Download page - Roadmap > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-5067) branch Jackrabbit 2.22
[ https://issues.apache.org/jira/browse/JCR-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853018#comment-17853018 ] Julian Reschke commented on JCR-5067: - CI: https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.22/ > branch Jackrabbit 2.22 > -- > > Key: JCR-5067 > URL: https://issues.apache.org/jira/browse/JCR-5067 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Jackrabbit 2.22 will be the first stable branch requiring Java 11, and will > be used in future stable Oak release (from trunk). > (It's also the first stable branch not to include any RMI support, see > https://issues.apache.org/jira/browse/JCR-4972. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Priority: Minor (was: Critical) ok, thanks for cross-checking, i will get in touch with support. lowering priority here. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853015#comment-17853015 ] Julian Reschke commented on JCRVLT-756: --- It appears Konrad is right. I was not able to confirm that the problem is indeed caused by a filevault change. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852838#comment-17852838 ] Konrad Windszus commented on JCRVLT-756: This points more to a problem in AEM than a general one in FileVault then. I would recommend involving Adobe support. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852828#comment-17852828 ] Stefan Seifert commented on JCRVLT-756: --- i've seen there are a lot of ITs around sub packages already in [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core-it/vault-core-integration-tests/src/main/java/org/apache/jackrabbit/vault/packaging/integration/SubPackagesIT.java] - i tried uploading different "all" packages to AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 and they all fail. i'm not sure if it's really a problem related to the vault impl, but there was the change mentioned above exactly between those two versions. maybe someone more knowledgeable in the vault impl then myself can take a look to get a better idea in which area the problem is located. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852772#comment-17852772 ] Konrad Windszus commented on JCRVLT-756: [~sseifert] Any chance you can come up with a failing IT? > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852750#comment-17852750 ] Stefan Seifert commented on JCRVLT-756: --- the two tickets which changed the vlt behavior between those two commits are JCRVLT-745 and JCRVLT-751 - but i do not see how they should break the install behavior in this way. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Description: i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i've attached log files with the package install procedure with both those versions. was: i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i'm attached log files with the package install procedure with both those versions. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated JCRVLT-756: -- Attachment: vault_installer_2024.5.16461.20240524T172309Z-240500.log vault_installer_2024.5.16544.20240530T165853Z-240500.log > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i'm attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-756) Sub packages contained in "all" package no longer installed
Stefan Seifert created JCRVLT-756: - Summary: Sub packages contained in "all" package no longer installed Key: JCRVLT-756 URL: https://issues.apache.org/jira/browse/JCRVLT-756 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Affects Versions: 3.7.4 Reporter: Stefan Seifert Attachments: vault_installer_2024.5.16461.20240524T172309Z-240500.log, vault_installer_2024.5.16544.20240530T165853Z-240500.log i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to install a package that includes sub packages - the sub packages are extracted, but not installed themselves properly. it seems the functionality broke with one of the recent commits: * it works fine with 3.7.3-T20240308111857-81fa88f1 * but does no longer work with 3.7.3-T20240514105118-694f6aea * differences between those two revs: [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] i tested with AEMaaCS SDK in two different versions - steps to reproduce the problem: * setup a local AEMaaCS SDK instance * upload package [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] * install this package * expected behavior: the package included the 5 subpackages should be extracted in packaged manager and all of them should be installed this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which includes 3.7.3-T20240308111857-81fa88f1 it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 which includes 3.7.3-T20240514105118-694f6aea i'm attached log files with the package install procedure with both those versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
Christian Schneider created JCRVLT-755: -- Summary: All contents are deleted when a content package created from a folder is applied Key: JCRVLT-755 URL: https://issues.apache.org/jira/browse/JCRVLT-755 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Reporter: Christian Schneider We have a strange issue where replication of a folder deletes all contents of the folder on destination system. We create a filevault package from the folder and apply the package using filevault on the destination system. It seems the behaviour is different depending if the folder or parent folder has a jcr:content sub node. I will provide one sample package where the issue occurs and one where the issue does not occur. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5066) Release Jackrabbit 2.21.27-beta
[ https://issues.apache.org/jira/browse/JCR-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-5066. - Resolution: Fixed > Release Jackrabbit 2.21.27-beta > --- > > Key: JCR-5066 > URL: https://issues.apache.org/jira/browse/JCR-5066 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCR-5066) Release Jackrabbit 2.21.27-beta
[ https://issues.apache.org/jira/browse/JCR-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed JCR-5066. --- > Release Jackrabbit 2.21.27-beta > --- > > Key: JCR-5066 > URL: https://issues.apache.org/jira/browse/JCR-5066 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCR-3943) [jackrabbi-aws-ext] Data inconsistency due to race condition during async uploads
[
https://issues.apache.org/jira/browse/JCR-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke closed JCR-3943.
---
> [jackrabbi-aws-ext] Data inconsistency due to race condition during async
> uploads
> -
>
> Key: JCR-3943
> URL: https://issues.apache.org/jira/browse/JCR-3943
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 2.22, 2.22.0
>
> Attachments: coredata14Nov5Dec.txt
>
>
> There is a race condition when {{LocalCache}} is used where if an upload
> ({{file_u}}) has entered the cache but not the {{AsyncUploadCache}} and a
> simultaneous PurgeJob is running, then the uploaded file {{file_u}} can be
> purged from the cache.
> When the async job ultimately runs it fails silently (S3 client fails to
> calculate the hash because of the missing file), thus leaving dangling
> references in the node store as well as the {{AsyncUploadCache}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-4023) [S3DS] Configure failure count in initial migration of blobs from file system to S3
[ https://issues.apache.org/jira/browse/JCR-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4023: Fix Version/s: 2.24 (was: 2.22) (was: 2.22.0) > [S3DS] Configure failure count in initial migration of blobs from file system > to S3 > --- > > Key: JCR-4023 > URL: https://issues.apache.org/jira/browse/JCR-4023 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-data >Affects Versions: 2.13.3 >Reporter: Shashank Gupta >Assignee: Amit Jain >Priority: Major > Fix For: 2.24 > > Attachments: JCR-4023.patch > > > Currently initial migration fails if there is any intermittent error for > uploading file to S3. The idea is to continue with migration until failures > reaches configurable limit. On reaching limit migration or traversing whole > list of files, migration will abort. > This way next migration has less number to upload to S3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4773) upgrade pax-exam test dependency
[ https://issues.apache.org/jira/browse/JCR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4773: Fix Version/s: 2.24 (was: 2.22) (was: 2.22.0) > upgrade pax-exam test dependency > > > Key: JCR-4773 > URL: https://issues.apache.org/jira/browse/JCR-4773 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: test >Reporter: Julian Reschke >Assignee: Manfred Baedke >Priority: Major > Fix For: 2.24 > > Attachments: exam-4.13.2.diff, patch-for-185.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4610) Tests in jackrabbit-spi2dav are not executed by default
[
https://issues.apache.org/jira/browse/JCR-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-4610:
Fix Version/s: 2.24
(was: 2.22)
(was: 2.22.0)
> Tests in jackrabbit-spi2dav are not executed by default
> ---
>
> Key: JCR-4610
> URL: https://issues.apache.org/jira/browse/JCR-4610
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-spi2dav
>Affects Versions: 2.21.2
>Reporter: Konrad Windszus
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.24
>
>
> The (integration) tests below
> https://github.com/apache/jackrabbit/blob/0f0807d25283b8786d800dcc41821443f43c2f82/jackrabbit-spi2dav/pom.xml#L41
> are skipped by default.
> They require a Jackrabbit Server running on localhost:8080 but this is not
> started automatically during a regular Maven Build.
> It would be good to
> # run those ITs with maven-failsafe-plugin (instead of maven-surefire-plugin)
> and rename the test classes accordingly
> # first start a Jackrabbit Server similar to how it is done in
> {{jackrabbit-jcr2dav}} and stop it accordingly after tests have been executed
> # use the same profile "integrationTests" as for the other modules
> Remark: The commons JCR test suite is checked via a DavEx client in
> {{jackrabbit-jcr2dav}} but all specific tests from
> https://github.com/apache/jackrabbit/tree/trunk/jackrabbit-spi2dav/src/test/java/org/apache/jackrabbit
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4926: Fix Version/s: 2.24 (was: 2.22) (was: 2.22.0) > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Major > Fix For: 2.24 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4073) jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge
[
https://issues.apache.org/jira/browse/JCR-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-4073:
Fix Version/s: 2.24
(was: 2.22)
(was: 2.22.0)
> jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge
> -
>
> Key: JCR-4073
> URL: https://issues.apache.org/jira/browse/JCR-4073
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
>Reporter: Julian Reschke
>Assignee: Amit Jain
>Priority: Major
> Fix For: 2.24
>
>
> {noformat}
> Error Message
> a1 should be null
> Stacktrace
> junit.framework.AssertionFailedError: a1 should be null
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertNull(Assert.java:237)
> at
> org.apache.jackrabbit.core.data.TestLocalCache.testAutoPurge(TestLocalCache.java:197)
> {noformat}
> Maybe caused by JCR-4007?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5048) Jackrabbit should build and test with Java 23
[
https://issues.apache.org/jira/browse/JCR-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-5048:
Fix Version/s: 2.24
(was: 2.22)
(was: 2.22.0)
> Jackrabbit should build and test with Java 23
> -
>
> Key: JCR-5048
> URL: https://issues.apache.org/jira/browse/JCR-5048
> Project: Jackrabbit Content Repository
> Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.24
>
>
> Right now:
> {noformat}
> Caused by: java.lang.IllegalStateException:
> Byte Buddy could not instrument all classes within the mock's type hierarchy
> This problem should never occur for javac-compiled classes. This problem has
> been observed for classes that are:
> - Compiled by older versions of scalac
> - Classes that are part of the Android distribution
> at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:285)
> at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:218)
> at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:78)
> at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:168)
> at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:399)
> at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:190)
> at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:410)
> at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:75)
> at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:414)
> at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:373)
> at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:352)
> at
> org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
> at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:99)
> at org.mockito.internal.MockitoCore.mock(MockitoCore.java:84)
> at org.mockito.Mockito.spy(Mockito.java:2224)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException: Java 23 (67) is not supported
> by the current version of Byte Buddy which officially supports Java 22 (66) -
> update Byte Buddy or set net.bytebuddy.experimental as a VM property
> at
> net.bytebuddy.utility.OpenedClassReader.of(OpenedClassReader.java:100)
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining.create(TypeWriter.java:4011)
> at
> net.bytebuddy.dynamic.scaffold.TypeWriter$Default.make(TypeWriter.java:2224)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$UsingTypeWriter.make(DynamicType.java:4055)
> at
> net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase.make(DynamicType.java:3739)
> at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.transform(InlineBytecodeGenerator.java:402)
> at
> java.instrument/java.lang.instrument.ClassFileTransformer.transform(ClassFileTransformer.java:242)
> at
> java.instrument/sun.instrument.TransformerManager.transform(TransformerManager.java:188)
> at
> java.instrument/sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:610)
> at
> java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native
> Method)
> at
> java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:225)
> at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:281)
> ... 34 more
> {noformat}
> Probably requires mockito/bytebuddy updates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()
[
https://issues.apache.org/jira/browse/JCR-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3995:
Fix Version/s: 2.24
(was: 2.22)
(was: 2.22.0)
> occasional test failure in
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
>
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
>Affects Versions: 2.13.0, 2.10.5
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 2.24
>
> Attachments: JCR-3995-new.patch, JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
> Time elapsed: 0.084 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
