[jira] [Closed] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-769. -- > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 using the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-780) Remove @Component annotations
[ https://issues.apache.org/jira/browse/JCRVLT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-780. -- > Remove @Component annotations > - > > Key: JCRVLT-780 > URL: https://issues.apache.org/jira/browse/JCRVLT-780 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > Use JSR-330 annotations instead. Compare with > https://issues.apache.org/jira/browse/MPLUGIN-530. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-765) Update to FileVault 3.8.2
[ https://issues.apache.org/jira/browse/JCRVLT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-765. -- > Update to FileVault 3.8.2 > - > > Key: JCRVLT-765 > URL: https://issues.apache.org/jira/browse/JCRVLT-765 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > [https://github.com/apache/jackrabbit-filevault/blob/master/RELEASE-NOTES.txt] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (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 closed JCRVLT-757. -- > 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.4.0 > > > 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)
[RESULT] [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.4.0
Hi there, The vote passes with +1 votes from Julian, Manfred and myself. Thanks for voting. I'll push the release out. Konrad > On 25. Sep 2024, at 20:38, Konrad Windszus wrote: > > Hello, > > A candidate for the Jackrabbit FileVault Package Maven Plugin 1.4.0 release > is available at: > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.4.0/ > > The release candidate is a zip archive of the sources in: > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.4.0/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354219 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault-plugin 1.4.0 > (You may need to update the check-release.sh from SVN first due to some > updates) > > A staged Maven repository is available for review at: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1694 > > Please vote on releasing this package as Apache Jackrabbit FileVault Package > Maven Plugin 1.4.0. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven > Plugin 1.4.0 > [ ] -1 Do not release this package because… > > Thanks in advance for voting > Konrad
Re: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.4.0
Here is my +1 Konrad > On 25. Sep 2024, at 20:38, Konrad Windszus wrote: > > Hello, > > A candidate for the Jackrabbit FileVault Package Maven Plugin 1.4.0 release > is available at: > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.4.0/ > > The release candidate is a zip archive of the sources in: > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.4.0/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354219 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault-plugin 1.4.0 > (You may need to update the check-release.sh from SVN first due to some > updates) > > A staged Maven repository is available for review at: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1694 > > Please vote on releasing this package as Apache Jackrabbit FileVault Package > Maven Plugin 1.4.0. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven > Plugin 1.4.0 > [ ] -1 Do not release this package because… > > Thanks in advance for voting > Konrad
Re: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.4.0
Hi Julian, We are bound to SVN for the distribution because that is the only means offered by the ASF for distribution: https://infra.apache.org/release-publishing.html#distribution >>> Could you include a link to the SVN repo where I could find >>> check-release.sh? It's been a while since nearly everything was >>> migrated to git ... Yes, I can do that but the script is the same used for all Jackrabbit releases (Oak, JR2, FileVault, ….) so it seems it really is a while since you last engaged in the release process… > Sorry, still can't vote. My svn command is broken and I haven't got > the time to investigate how to fix it. Unfortunately, the script > relies on the svn command. It is not mandatory to rely on the script, compare with https://www.apache.org/legal/release-policy.html#release-approval. Konrad > On 26. Sep 2024, at 09:31, Julian Sedding wrote: > > Sorry, still can't vote. My svn command is broken and I haven't got > the time to investigate how to fix it. Unfortunately, the script > relies on the svn command. > > Julian > > On Thu, 26 Sept 2024 at 09:24, Julian Sedding wrote: >> >> Ah, finally found it: >> https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh >> >> Maybe it helps someone else. >> >> Julian >> >> On Thu, 26 Sept 2024 at 09:23, Julian Sedding wrote: >>> >>> Hi Konrad >>> >>> Could you include a link to the SVN repo where I could find >>> check-release.sh? It's been a while since nearly everything was >>> migrated to git ... >>> >>> BTW, do you know if there is any reason why this script is not in git? >>> And maybe closer to where it's needed? >>> >>> Thanks >>> Julian >>> >>> On Wed, 25 Sept 2024 at 20:38, Konrad Windszus wrote: >>>> >>>> Hello, >>>> >>>> A candidate for the Jackrabbit FileVault Package Maven Plugin 1.4.0 >>>> release is available at: >>>> https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.4.0/ >>>> >>>> The release candidate is a zip archive of the sources in: >>>> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.4.0/ >>>> >>>> The release notes can be found in JIRA at >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354219 >>>> >>>> The command for running automated checks against this release candidate is: >>>> $ sh check-release.sh filevault-plugin 1.4.0 >>>> (You may need to update the check-release.sh from SVN first due to some >>>> updates) >>>> >>>> A staged Maven repository is available for review at: >>>> https://repository.apache.org/content/repositories/orgapachejackrabbit-1694 >>>> >>>> Please vote on releasing this package as Apache Jackrabbit FileVault >>>> Package Maven Plugin 1.4.0. >>>> The vote is open for a minimum of 72 hours during business days and passes >>>> if a majority of at least three +1 Jackrabbit PMC votes are cast. >>>> The vote fails if not enough votes are cast after 1 week (5 business days). >>>> >>>> [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven >>>> Plugin 1.4.0 >>>> [ ] -1 Do not release this package because… >>>> >>>> Thanks in advance for voting >>>> Konrad
[VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.4.0
Hello, A candidate for the Jackrabbit FileVault Package Maven Plugin 1.4.0 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.4.0/ The release candidate is a zip archive of the sources in: https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.4.0/ The release notes can be found in JIRA at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354219 The command for running automated checks against this release candidate is: $ sh check-release.sh filevault-plugin 1.4.0 (You may need to update the check-release.sh from SVN first due to some updates) A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1694 Please vote on releasing this package as Apache Jackrabbit FileVault Package Maven Plugin 1.4.0. The vote is open for a minimum of 72 hours during business days and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. The vote fails if not enough votes are cast after 1 week (5 business days). [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven Plugin 1.4.0 [ ] -1 Do not release this package because… Thanks in advance for voting Konrad
[jira] [Created] (JCRVLT-785) Remove License and Notice from Git Repo
Konrad Windszus created JCRVLT-785: -- Summary: Remove License and Notice from Git Repo Key: JCRVLT-785 URL: https://issues.apache.org/jira/browse/JCRVLT-785 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Reporter: Konrad Windszus Assignee: Konrad Windszus As License and Notice is automatically added to the Source archive via https://maven.apache.org/apache-resource-bundles/jar/ there is no need to also maintain that separately in the Git repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-780) Remove @Component annotations
[ https://issues.apache.org/jira/browse/JCRVLT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-780: --- Issue Type: Improvement (was: Bug) > Remove @Component annotations > - > > Key: JCRVLT-780 > URL: https://issues.apache.org/jira/browse/JCRVLT-780 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > Use JSR-330 annotations instead. Compare with > https://issues.apache.org/jira/browse/MPLUGIN-530. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-765) Update to FileVault 3.8.2
[ https://issues.apache.org/jira/browse/JCRVLT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-765: --- Summary: Update to FileVault 3.8.2 (was: Update to FileVault 3.8.0) > Update to FileVault 3.8.2 > - > > Key: JCRVLT-765 > URL: https://issues.apache.org/jira/browse/JCRVLT-765 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > [https://github.com/apache/jackrabbit-filevault/blob/master/RELEASE-NOTES.txt] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-777) ITs fail in Maven 4
[
https://issues.apache.org/jira/browse/JCRVLT-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-777:
---
Fix Version/s: package-maven-plugin-1.4.2
(was: package-maven-plugin-1.4.0)
> ITs fail in Maven 4
> ---
>
> Key: JCRVLT-777
> URL: https://issues.apache.org/jira/browse/JCRVLT-777
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.4.2
>
>
> Currently the execution of ITs in Maven 4 (beta 2) fail with the following
> issue
>
> {code}
> org.opentest4j.AssertionFailedError:
> filter.xml is incorrect ==> expected: <
>
>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle2-1.0.0-SNAPSHOT.jar"/>
>
> root="/etc/packages/test/package-plugin-test-pkg-sub1-1.0.0-SNAPSHOT.zip"/>
> root="/etc/packages/test/package-plugin-test-pkg-sub2-1.0.0-SNAPSHOT.zip"/>
>
> > but was: <
>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle1-1.0.0-SNAPSHOT.jar"/>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle2-1.0.0-SNAPSHOT.jar"/>
>
> root="/etc/packages/test/package-plugin-test-pkg-sub1-1.0.0-SNAPSHOT.zip"/>
> root="/etc/packages/test/package-plugin-test-pkg-sub2-1.0.0-SNAPSHOT.zip"/>
>
> >
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:474)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:456)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.GenerateMetadataMultiModuleIT.multi_module_build_clean_package(GenerateMetadataMultiModuleIT.java:59)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
>
[jira] [Updated] (JCRVLT-781) Require Java 11
[ https://issues.apache.org/jira/browse/JCRVLT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-781: --- Fix Version/s: (was: package-maven-plugin-1.4.0) > Require Java 11 > > > Key: JCRVLT-781 > URL: https://issues.apache.org/jira/browse/JCRVLT-781 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > > In order to get rid of the Commons IO dependencies and leverage Jackrabbit > API/Commons 2.22.x (requiring Java 11) FileVault should require Java 11 as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-774) Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency)
[ https://issues.apache.org/jira/browse/JCRVLT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-774. -- > Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency) > -- > > Key: JCRVLT-774 > URL: https://issues.apache.org/jira/browse/JCRVLT-774 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > Currently the implementation of > https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/context/AbstractDependencyResolver.java#L98 > cannot be overwritten by subclasses. > This is crucial though to e.g. apply some mapping from Dependency to Maven > coordinates or to use a different heuristics to find available versions > satisfying a version range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-772) Remove JUnit 3
[
https://issues.apache.org/jira/browse/JCRVLT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-772.
--
> Remove JUnit 3
> --
>
> Key: JCRVLT-772
> URL: https://issues.apache.org/jira/browse/JCRVLT-772
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.2
>
>
> Some tests still rely on ancient JUnit 3 (package {{junit.framework}}). In
> order to move forward those should be converted to JUnit 4 (to be ultimately
> replaced by JUnit 5 ones).
> https://github.com/search?q=repo%3Aapache%2Fjackrabbit-filevault%20junit.framework&type=code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-778.
--
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.2
>
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range they are different objects.
> The {{equals}} method neglects those difference but reusing the constant
> {{VersionRange.INFINITE}} improves the memory footprint and allows to use the
> same instance check for infinite version ranges.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-776) improve test coverage for IdConflictPolicy
[ https://issues.apache.org/jira/browse/JCRVLT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-776. -- > improve test coverage for IdConflictPolicy > -- > > Key: JCRVLT-776 > URL: https://issues.apache.org/jira/browse/JCRVLT-776 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 3.8.2 > > > to include four different target repo state (conflict-moved, > conflict-in-place, no-conflict-target-gone, no-conflict-target-present) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-768) vlt: when DEBUG logging stashing ops, add the IdConflictPolicy as well
[ https://issues.apache.org/jira/browse/JCRVLT-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-768. -- > vlt: when DEBUG logging stashing ops, add the IdConflictPolicy as well > -- > > Key: JCRVLT-768 > URL: https://issues.apache.org/jira/browse/JCRVLT-768 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 3.8.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-783) site.xml no longer deployed in FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-783. -- > site.xml no longer deployed in FileVault 3.8.0 > -- > > Key: JCRVLT-783 > URL: https://issues.apache.org/jira/browse/JCRVLT-783 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Misc >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > The site.xml of the parent is no longer deployed for FileVault 3.8.0: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.8.0/ > while it is still there in older versions: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.7.2/ > Somehow the [attach-descriptor > goal|https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html] > has no longer been executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Jackrabbit FileVault 3.8.2
Hi, The vote passed with +1 from Manfred, Jörg and Julian. Thanks for voting, I am gonna push the release out to ASF and Central. Konrad > On 20. Sep 2024, at 17:40, Konrad Windszus wrote: > > Hi, > A candidate for the Jackrabbit FileVault 3.8.2 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.8.2/ > > The release candidate is a zip archive of the sources in: > > https://github.com/apache/jackrabbit-filevault/tree/jackrabbit-filevault-3.8.2/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354676 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault 3.8.2 > (leveraging the script from > https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh) > > A staged Maven repository is available for review at: > > https://repository.apache.org/content/repositories/orgapachejackrabbit-1692 > > Please vote on releasing this package as Apache Jackrabbit FileVault 3.8.2. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault 3.8.2 > [ ] -1 Do not release this package because... > > Thanks in advance for voting, > Konrad
[jira] [Commented] (JCRVLT-779) Deletion of a container package doesn't delete its embedded packages and subpackages
[ https://issues.apache.org/jira/browse/JCRVLT-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883831#comment-17883831 ] Konrad Windszus commented on JCRVLT-779: TBH I fail to see a convincing use case for automatically deleting packages when deleting the container. Also for me uninstallation and package deletion is kind of orthogonal. Compare also with the related https://issues.apache.org/jira/browse/JCRVLT-524. > Deletion of a container package doesn't delete its embedded packages and > subpackages > > > Key: JCRVLT-779 > URL: https://issues.apache.org/jira/browse/JCRVLT-779 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Ankita Agarwal >Priority: Major > > When a container package is deleted, its embedded and subpackages are not > removed. > The process of deleting a package should follow the same behaviour as > installing and uninstalling packages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[VOTE] Release Apache Jackrabbit FileVault 3.8.2
Hi, A candidate for the Jackrabbit FileVault 3.8.2 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.8.2/ The release candidate is a zip archive of the sources in: https://github.com/apache/jackrabbit-filevault/tree/jackrabbit-filevault-3.8.2/ The release notes can be found in JIRA at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12354676 The command for running automated checks against this release candidate is: $ sh check-release.sh filevault 3.8.2 (leveraging the script from https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh) A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1692 Please vote on releasing this package as Apache Jackrabbit FileVault 3.8.2. The vote is open for a minimum of 72 hours during business days and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. The vote fails if not enough votes are cast after 1 week (5 business days). [ ] +1 Release this package as Apache Jackrabbit FileVault 3.8.2 [ ] -1 Do not release this package because... Thanks in advance for voting, Konrad
[jira] [Resolved] (JCRVLT-775) Support explicit mapping of Dependency -> Maven coordinates in AbstractDependencyResolver
[ https://issues.apache.org/jira/browse/JCRVLT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-775. Resolution: Won't Fix > Support explicit mapping of Dependency -> Maven coordinates in > AbstractDependencyResolver > - > > Key: JCRVLT-775 > URL: https://issues.apache.org/jira/browse/JCRVLT-775 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Affects Versions: 3.8.0 >Reporter: Konrad Windszus >Priority: Major > > Currently AbstractDependencyResolver only uses some heuristics to derive > Maven coordinates from a given package dependency. It should optionally > support explicit mappings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-775) Support explicit mapping of Dependency -> Maven coordinates in AbstractDependencyResolver
[ https://issues.apache.org/jira/browse/JCRVLT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-775: --- Fix Version/s: (was: 3.8.2) > Support explicit mapping of Dependency -> Maven coordinates in > AbstractDependencyResolver > - > > Key: JCRVLT-775 > URL: https://issues.apache.org/jira/browse/JCRVLT-775 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Priority: Major > > Currently AbstractDependencyResolver only uses some heuristics to derive > Maven coordinates from a given package dependency. It should optionally > support explicit mappings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-775) Support explicit mapping of Dependency -> Maven coordinates in AbstractDependencyResolver
[ https://issues.apache.org/jira/browse/JCRVLT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883254#comment-17883254 ] Konrad Windszus commented on JCRVLT-775: The mappings can be easily supported with an extension of AbstractDependencyResolver and the format depends a lot on then context, therefore probably not a good idea to implement in the abstract base class. > Support explicit mapping of Dependency -> Maven coordinates in > AbstractDependencyResolver > - > > Key: JCRVLT-775 > URL: https://issues.apache.org/jira/browse/JCRVLT-775 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Affects Versions: 3.8.0 >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > Currently AbstractDependencyResolver only uses some heuristics to derive > Maven coordinates from a given package dependency. It should optionally > support explicit mappings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-783) site.xml no longer deployed in FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-783. Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault/commit/b5d147bb80dc7107e6cb8f47aa64d55df1720526. > site.xml no longer deployed in FileVault 3.8.0 > -- > > Key: JCRVLT-783 > URL: https://issues.apache.org/jira/browse/JCRVLT-783 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Misc >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > The site.xml of the parent is no longer deployed for FileVault 3.8.0: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.8.0/ > while it is still there in older versions: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.7.2/ > Somehow the [attach-descriptor > goal|https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html] > has no longer been executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-783) site.xml no longer deployed in FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-783: -- Assignee: Konrad Windszus > site.xml no longer deployed in FileVault 3.8.0 > -- > > Key: JCRVLT-783 > URL: https://issues.apache.org/jira/browse/JCRVLT-783 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Misc >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > The site.xml of the parent is no longer deployed for FileVault 3.8.0: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.8.0/ > while it is still there in older versions: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.7.2/ > Somehow the [attach-descriptor > goal|https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html] > has no longer been executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-783) site.xml no longer deployed in FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882135#comment-17882135 ] Konrad Windszus commented on JCRVLT-783: This is a regression of https://issues.apache.org/jira/browse/MPOM-480 introduced with JCRVLT-759. > site.xml no longer deployed in FileVault 3.8.0 > -- > > Key: JCRVLT-783 > URL: https://issues.apache.org/jira/browse/JCRVLT-783 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Misc >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > The site.xml of the parent is no longer deployed for FileVault 3.8.0: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.8.0/ > while it is still there in older versions: > https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.7.2/ > Somehow the [attach-descriptor > goal|https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html] > has no longer been executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-783) site.xml no longer deployed in FileVault 3.8.0
Konrad Windszus created JCRVLT-783: -- Summary: site.xml no longer deployed in FileVault 3.8.0 Key: JCRVLT-783 URL: https://issues.apache.org/jira/browse/JCRVLT-783 Project: Jackrabbit FileVault Issue Type: Bug Components: Misc Affects Versions: 3.8.0 Reporter: Konrad Windszus Fix For: 3.8.2 The site.xml of the parent is no longer deployed for FileVault 3.8.0: https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.8.0/ while it is still there in older versions: https://repo1.maven.org/maven2/org/apache/jackrabbit/vault/parent/3.7.2/ Somehow the [attach-descriptor goal|https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html] has no longer been executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-782) Introduce spotless-maven-plugin
[ https://issues.apache.org/jira/browse/JCRVLT-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-782: --- Description: Leverage automated source code formatting (for both Java and POM.xml files) with [spotless-maven-plugin|https://github.com/diffplug/spotless/tree/main/plugin-maven]. Proposal: - leverage [google-java-format|https://github.com/google/google-java-format] as [palantir failed to adopt Java 21 features for a long time|https://github.com/palantir/palantir-java-format/pull/935] and also seems to lack maintenance in general. was: Leverage automated source code formatting (for both Java and POM.xml files) with [spotless-maven-plugin|https://github.com/diffplug/spotless/tree/main/plugin-maven]. Proposal: - leverage [google-java-format|https://github.com/google/google-java-format] as [palantir|https://github.com/palantir/palantir-java-format/pull/935 failed to adopt Java 21 features for a long time] and also seems to lack maintenance. > Introduce spotless-maven-plugin > --- > > Key: JCRVLT-782 > URL: https://issues.apache.org/jira/browse/JCRVLT-782 > Project: Jackrabbit FileVault > Issue Type: Improvement > Reporter: Konrad Windszus >Priority: Major > > Leverage automated source code formatting (for both Java and POM.xml files) > with > [spotless-maven-plugin|https://github.com/diffplug/spotless/tree/main/plugin-maven]. > Proposal: > - leverage [google-java-format|https://github.com/google/google-java-format] > as [palantir failed to adopt Java 21 features for a long > time|https://github.com/palantir/palantir-java-format/pull/935] and also > seems to lack maintenance in general. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-782) Introduce spotless-maven-plugin
Konrad Windszus created JCRVLT-782: -- Summary: Introduce spotless-maven-plugin Key: JCRVLT-782 URL: https://issues.apache.org/jira/browse/JCRVLT-782 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Konrad Windszus Leverage automated source code formatting (for both Java and POM.xml files) with [spotless-maven-plugin|https://github.com/diffplug/spotless/tree/main/plugin-maven]. Proposal: - leverage [google-java-format|https://github.com/google/google-java-format] as [palantir|https://github.com/palantir/palantir-java-format/pull/935 failed to adopt Java 21 features for a long time] and also seems to lack maintenance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-781) Require Java 11
[ https://issues.apache.org/jira/browse/JCRVLT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-781: --- Fix Version/s: package-maven-plugin-1.4.0 > Require Java 11 > > > Key: JCRVLT-781 > URL: https://issues.apache.org/jira/browse/JCRVLT-781 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > In order to get rid of the Commons IO dependencies and leverage Jackrabbit > API/Commons 2.22.x (requiring Java 11) FileVault should require Java 11 as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-781) Require Java 11
Konrad Windszus created JCRVLT-781: -- Summary: Require Java 11 Key: JCRVLT-781 URL: https://issues.apache.org/jira/browse/JCRVLT-781 Project: Jackrabbit FileVault Issue Type: Improvement Components: Misc Reporter: Konrad Windszus In order to get rid of the Commons IO dependencies and leverage Jackrabbit API/Commons 2.22.x (requiring Java 11) FileVault should require Java 11 as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-781) Require Java 11
[ https://issues.apache.org/jira/browse/JCRVLT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-781: --- Component/s: package maven plugin (was: Misc) > Require Java 11 > > > Key: JCRVLT-781 > URL: https://issues.apache.org/jira/browse/JCRVLT-781 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > > In order to get rid of the Commons IO dependencies and leverage Jackrabbit > API/Commons 2.22.x (requiring Java 11) FileVault should require Java 11 as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-769. Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/ba803af0ffe266d2b3b4eda834b438b46cfd255e. > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 using the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-780) Remove @Component annotations
[ https://issues.apache.org/jira/browse/JCRVLT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-780. Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/a20c210d207b9ac2447eb94ac4a2082ef093c57d. > Remove @Component annotations > - > > Key: JCRVLT-780 > URL: https://issues.apache.org/jira/browse/JCRVLT-780 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > Use JSR-330 annotations instead. Compare with > https://issues.apache.org/jira/browse/MPLUGIN-530. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-780) Remove @Component annotations
[ https://issues.apache.org/jira/browse/JCRVLT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-780: -- Assignee: Konrad Windszus > Remove @Component annotations > - > > Key: JCRVLT-780 > URL: https://issues.apache.org/jira/browse/JCRVLT-780 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > Use JSR-330 annotations instead. Compare with > https://issues.apache.org/jira/browse/MPLUGIN-530. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-780) Remove @Component annotations
Konrad Windszus created JCRVLT-780: -- Summary: Remove @Component annotations Key: JCRVLT-780 URL: https://issues.apache.org/jira/browse/JCRVLT-780 Project: Jackrabbit FileVault Issue Type: Bug Components: package maven plugin Reporter: Konrad Windszus Fix For: package-maven-plugin-1.4.0 Use JSR-330 annotations instead. Compare with https://issues.apache.org/jira/browse/MPLUGIN-530. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-778:
---
Fix Version/s: 3.8.2
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.2
>
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range they are different objects.
> The {{equals}} method neglects those difference but reusing the constant
> {{VersionRange.INFINITE}} improves the memory footprint and allows to use the
> same instance check for infinite version ranges.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved JCRVLT-778.
Resolution: Fixed
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.2
>
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range they are different objects.
> The {{equals}} method neglects those difference but reusing the constant
> {{VersionRange.INFINITE}} improves the memory footprint and allows to use the
> same instance check for infinite version ranges.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-778:
---
Component/s: Packaging
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range they are different objects.
> The {{equals}} method neglects those difference but reusing the constant
> {{VersionRange.INFINITE}} improves the memory footprint and allows to use the
> same instance check for infinite version ranges.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-778:
---
Description:
The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
true, null, true);}}
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
However the empty string (representing the infinite range as well) returns
{{new VersionRange(null, false, null, false)}} in
{{VersionRange.fromString(String)}}.
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
Although both represent the infinite range they are different objects.
The {{equals}} method neglects those difference but reusing the constant
{{VersionRange.INFINITE}} improves the memory footprint and allows to use the
same instance check for infinite version ranges.
was:
The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
true, null, true);}}
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
However the empty string (representing the infinite range as well) returns
{{new VersionRange(null, false, null, false)}} in
{{VersionRange.fromString(String)}}.
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
Although both represent the infinite range, they are not equal.
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range they are different objects.
> The {{equals}} method neglects those difference but reusing the constant
> {{VersionRange.INFINITE}} improves the memory footprint and allows to use the
> same instance check for infinite version ranges.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned JCRVLT-778:
--
Assignee: Konrad Windszus
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range, they are not equal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
[
https://issues.apache.org/jira/browse/JCRVLT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-778:
---
Issue Type: Bug (was: Improvement)
> VersionRange.fromString("") does not return VersionRange.INFINITE
> -
>
> Key: JCRVLT-778
> URL: https://issues.apache.org/jira/browse/JCRVLT-778
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Reporter: Konrad Windszus
>Priority: Major
>
> The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
> true, null, true);}}
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
> However the empty string (representing the infinite range as well) returns
> {{new VersionRange(null, false, null, false)}} in
> {{VersionRange.fromString(String)}}.
> (https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
> Although both represent the infinite range, they are not equal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-778) VersionRange.fromString("") does not return VersionRange.INFINITE
Konrad Windszus created JCRVLT-778:
--
Summary: VersionRange.fromString("") does not return
VersionRange.INFINITE
Key: JCRVLT-778
URL: https://issues.apache.org/jira/browse/JCRVLT-778
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Konrad Windszus
The constant {{VersionRange.INFINITE}} is defined as {{new VersionRange(null,
true, null, true);}}
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L37)
However the empty string (representing the infinite range as well) returns
{{new VersionRange(null, false, null, false)}} in
{{VersionRange.fromString(String)}}.
(https://github.com/apache/jackrabbit-filevault/blob/b37c68091ba97ada6ea4b1c21d256ce45c79f17c/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VersionRange.java#L231)
Although both represent the infinite range, they are not equal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCRVLT-772) Remove JUnit 3
[
https://issues.apache.org/jira/browse/JCRVLT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved JCRVLT-772.
Fix Version/s: 3.8.2
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-filevault/commit/d417f9c87ca324c1e7fb1209bf47b16509e74b79.
> Remove JUnit 3
> --
>
> Key: JCRVLT-772
> URL: https://issues.apache.org/jira/browse/JCRVLT-772
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.2
>
>
> Some tests still rely on ancient JUnit 3 (package {{junit.framework}}). In
> order to move forward those should be converted to JUnit 4 (to be ultimately
> replaced by JUnit 5 ones).
> https://github.com/search?q=repo%3Aapache%2Fjackrabbit-filevault%20junit.framework&type=code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-777) Make ITs work in Maven 4
Konrad Windszus created JCRVLT-777:
--
Summary: Make ITs work in Maven 4
Key: JCRVLT-777
URL: https://issues.apache.org/jira/browse/JCRVLT-777
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Konrad Windszus
Fix For: package-maven-plugin-1.4.0
Currently the execution of ITs in Maven 4 (beta 2) fail with the following issue
{code}
org.opentest4j.AssertionFailedError:
filter.xml is incorrect ==> expected: <
> but was: <
>
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
at
org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
at
org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:474)
at
org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:456)
at
org.apache.jackrabbit.filevault.maven.packaging.it.GenerateMetadataMultiModuleIT.multi_module_build_clean_package(GenerateMetadataMultiModuleIT.java:59)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.Node
[jira] [Updated] (JCRVLT-777) ITs fail in Maven 4
[
https://issues.apache.org/jira/browse/JCRVLT-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-777:
---
Summary: ITs fail in Maven 4 (was: Make ITs work in Maven 4)
> ITs fail in Maven 4
> ---
>
> Key: JCRVLT-777
> URL: https://issues.apache.org/jira/browse/JCRVLT-777
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.4.0
>
>
> Currently the execution of ITs in Maven 4 (beta 2) fail with the following
> issue
>
> {code}
> org.opentest4j.AssertionFailedError:
> filter.xml is incorrect ==> expected: <
>
>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle2-1.0.0-SNAPSHOT.jar"/>
>
> root="/etc/packages/test/package-plugin-test-pkg-sub1-1.0.0-SNAPSHOT.zip"/>
> root="/etc/packages/test/package-plugin-test-pkg-sub2-1.0.0-SNAPSHOT.zip"/>
>
> > but was: <
>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle1-1.0.0-SNAPSHOT.jar"/>
> root="/apps/bundles/install/package-plugin-test-pkg-bundle2-1.0.0-SNAPSHOT.jar"/>
>
> root="/etc/packages/test/package-plugin-test-pkg-sub1-1.0.0-SNAPSHOT.zip"/>
> root="/etc/packages/test/package-plugin-test-pkg-sub2-1.0.0-SNAPSHOT.zip"/>
>
> >
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:474)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.util.ProjectBuilder.verifyExpectedFilter(ProjectBuilder.java:456)
> at
> org.apache.jackrabbit.filevault.maven.packaging.it.GenerateMetadataMultiModuleIT.multi_module_build_clean_package(GenerateMetadataMultiModuleIT.java:59)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMetho
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Description: JCRVLT-567 introduced the regression that the manual mapping from package dependency to Maven coordinates was no longer considered (caused by https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) In addition due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts without a valid version. was: JCRVLT-567 introduced the regression that the manual mapping from package dependency to Maven coordinates was no longer considered (caused by https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08) In addition due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts without a valid version. > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-769: -- Assignee: Konrad Windszus > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Affects Version/s: package-maven-plugin-1.3.0 > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Description: JCRVLT-567 introduced the regression that the manual mapping from package dependency to Maven coordinates was no longer considered (caused by https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) In addition due to https://issues.apache.org/jira/browse/MNG-8192 using the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts without a valid version. was: JCRVLT-567 introduced the regression that the manual mapping from package dependency to Maven coordinates was no longer considered (caused by https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) In addition due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts without a valid version. > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08#diff-fb5f20c363b40e1380878e34329d42d8c414e11448aa355a3bd0ecc7b79ad91cL100-L113) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 using the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Description: JCRVLT-567 introduced the regression that the manual mapping from package dependency to Maven coordinates was no longer considered (caused by https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08) In addition due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts without a valid version. was: JCRVLT-567 introduced the regression that Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] does no longer work, as Maven does no longer allow Artifacts without a valid version. > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that the manual mapping from package > dependency to Maven coordinates was no longer considered (caused by > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/829a08abebded00b9c15e4df709b96e28ca2ce08) > In addition due to https://issues.apache.org/jira/browse/MNG-8192 the > parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > throws exceptions on Maven > 3.6.2 as that does no longer allow Artifacts > without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Summary: mapPackageDependencyToMavenGa does no longer work (was: mapPackageDependencyToMavenGa does not work on Maven >= 3.6.2) > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > does no longer work, as Maven does no longer allow Artifacts without a valid > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-769) mapPackageDependencyToMavenGa does no longer work
[ https://issues.apache.org/jira/browse/JCRVLT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-769: --- Description: JCRVLT-567 introduced the regression that Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] does no longer work, as Maven does no longer allow Artifacts without a valid version. was:Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] does no longer work, as Maven does no longer allow Artifacts without a valid version. > mapPackageDependencyToMavenGa does no longer work > - > > Key: JCRVLT-769 > URL: https://issues.apache.org/jira/browse/JCRVLT-769 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > JCRVLT-567 introduced the regression that > Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter > [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] > does no longer work, as Maven does no longer allow Artifacts without a valid > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-567) Move ValidationContext implementation to validation module and export them
[
https://issues.apache.org/jira/browse/JCRVLT-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-567:
---
Description: The {{ValidationContext}} implementations in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/master/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/validator/impl/context
are useful for other clients than the Maven plugin (SLING-10866) and should
therefore be moved to the FileVault Validation module and exported. (was: The
{{ValidationContext}} implementations in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/master/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/validator/impl/context
are useful for other client than the Maven plugin (SLING-10866) and should
therefore be moved to the FileVault Validation module and exported.)
> Move ValidationContext implementation to validation module and export them
> --
>
> Key: JCRVLT-567
> URL: https://issues.apache.org/jira/browse/JCRVLT-567
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: validation
>Affects Versions: 3.5.4
> Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.0, 3.5.6
>
>
> The {{ValidationContext}} implementations in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/master/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/validator/impl/context
> are useful for other clients than the Maven plugin (SLING-10866) and should
> therefore be moved to the FileVault Validation module and exported.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCRVLT-774) Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency)
[ https://issues.apache.org/jira/browse/JCRVLT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-774. Fix Version/s: 3.8.2 Assignee: Konrad Windszus Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault/commit/2f6ca004557bef35eb04d929dbb297a2e7ee17a5 > Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency) > -- > > Key: JCRVLT-774 > URL: https://issues.apache.org/jira/browse/JCRVLT-774 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Affects Versions: 3.8.0 > Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.2 > > > Currently the implementation of > https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/context/AbstractDependencyResolver.java#L98 > cannot be overwritten by subclasses. > This is crucial though to e.g. apply some mapping from Dependency to Maven > coordinates or to use a different heuristics to find available versions > satisfying a version range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-775) Support explicit mapping of Dependency -> Maven coordinates in AbstractDependencyResolver
Konrad Windszus created JCRVLT-775: -- Summary: Support explicit mapping of Dependency -> Maven coordinates in AbstractDependencyResolver Key: JCRVLT-775 URL: https://issues.apache.org/jira/browse/JCRVLT-775 Project: Jackrabbit FileVault Issue Type: Improvement Components: validation Affects Versions: 3.8.0 Reporter: Konrad Windszus Fix For: 3.8.2 Currently AbstractDependencyResolver only uses some heuristics to derive Maven coordinates from a given package dependency. It should optionally support explicit mappings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-774) Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency)
Konrad Windszus created JCRVLT-774: -- Summary: Allow overwriting of AbstractDependencyResolver.resolvePackageInfo(Dependency) Key: JCRVLT-774 URL: https://issues.apache.org/jira/browse/JCRVLT-774 Project: Jackrabbit FileVault Issue Type: Improvement Components: validation Affects Versions: 3.8.0 Reporter: Konrad Windszus Currently the implementation of https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/context/AbstractDependencyResolver.java#L98 cannot be overwritten by subclasses. This is crucial though to e.g. apply some mapping from Dependency to Maven coordinates or to use a different heuristics to find available versions satisfying a version range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-773) Deprecate JcrConstants
Konrad Windszus created JCRVLT-773:
--
Summary: Deprecate JcrConstants
Key: JCRVLT-773
URL: https://issues.apache.org/jira/browse/JCRVLT-773
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Konrad Windszus
The class at
https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/util/JcrConstants.java
is redundant, as it
a) duplicates most constants from
https://github.com/apache/jackrabbit/blob/85e5d0cca855a2a4c43972fb2f97042a6b81e7e3/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/JcrConstants.java#L36
b) Using the constants with the expanded names from JCR 2.0 is more stable
anyhow: https://javadoc.io/doc/javax.jcr/jcr/latest/constant-values.html (from
{{javax.jcr.Node}}, {{javax.jcr.Property}} and {{javax.jcr.nodetype.NodeType}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-772) Remove JUnit 3
[
https://issues.apache.org/jira/browse/JCRVLT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872609#comment-17872609
]
Konrad Windszus commented on JCRVLT-772:
I am gonna try the script from
https://github.com/FranciscoBorges/junit3ToJunit4.
> Remove JUnit 3
> --
>
> Key: JCRVLT-772
> URL: https://issues.apache.org/jira/browse/JCRVLT-772
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
>
> Some tests still rely on ancient JUnit 3 (package {{junit.framework}}). In
> order to move forward those should be converted to JUnit 4 (to be ultimately
> replaced by JUnit 5 ones).
> https://github.com/search?q=repo%3Aapache%2Fjackrabbit-filevault%20junit.framework&type=code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-772) Remove JUnit 3
Konrad Windszus created JCRVLT-772:
--
Summary: Remove JUnit 3
Key: JCRVLT-772
URL: https://issues.apache.org/jira/browse/JCRVLT-772
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: vlt
Reporter: Konrad Windszus
Some tests still rely on ancient JUnit 3 (package {{junit.framework}}). In
order to move forward those should be converted to JUnit 4 (to be ultimately
replaced by JUnit 5 ones).
https://github.com/search?q=repo%3Aapache%2Fjackrabbit-filevault%20junit.framework&type=code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCRVLT-772) Remove JUnit 3
[
https://issues.apache.org/jira/browse/JCRVLT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned JCRVLT-772:
--
Assignee: Konrad Windszus
> Remove JUnit 3
> --
>
> Key: JCRVLT-772
> URL: https://issues.apache.org/jira/browse/JCRVLT-772
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
>
> Some tests still rely on ancient JUnit 3 (package {{junit.framework}}). In
> order to move forward those should be converted to JUnit 4 (to be ultimately
> replaced by JUnit 5 ones).
> https://github.com/search?q=repo%3Aapache%2Fjackrabbit-filevault%20junit.framework&type=code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-771) Dependency.fromString() should throw in case of invalid dependency coordinates
Konrad Windszus created JCRVLT-771:
--
Summary: Dependency.fromString() should throw in case of invalid
dependency coordinates
Key: JCRVLT-771
URL: https://issues.apache.org/jira/browse/JCRVLT-771
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: vlt
Reporter: Konrad Windszus
Currently Dependency.fromString() may return {@code null} and also invalid
Dependency objects (e.g. with empty name and/or group). Although empty group
may be fine (for packages directly in the top level), name must for sure be
non-empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-770) Refactor ServiceProvider to no longer cover JCR 2.0 vs 1.0 differences
[
https://issues.apache.org/jira/browse/JCRVLT-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-770:
---
Description:
The rest of the code already assumes a JCR 2.0 compliant implementation since
quite a while so the
[ServiceProvider|https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/ServiceProvider.java#L32C18-L32C33]
can be refactored that it only takes into account impl specific differences
(but no longer translations from JCR 2.0 to 1.0)
Candidates to remove:
- {{getJcrVersion()}} (always assume JCR 2.0)
- Remove features purely relying on JCR 2.0 API
- Maybe also make [Jackrabbit JCR API
Extensions|https://www.javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/index.html]
a fix requirement (which version?)
was:
The rest of the code already assumes a JCR 2.0 compliant implementation since
quite a while so the
[ServiceProvider|https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/ServiceProvider.java#L32C18-L32C33]
can be refactored that it only takes into account impl specific differences
(but no longer translations from JCR 2.0 to 1.0)
Candidates to remove:
- {{getJcrVersion()}} (always assume JCR 2.0)
- Remove features purely relying on JCR 2.0 API
> Refactor ServiceProvider to no longer cover JCR 2.0 vs 1.0 differences
> --
>
> Key: JCRVLT-770
> URL: https://issues.apache.org/jira/browse/JCRVLT-770
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Konrad Windszus
>Priority: Major
>
> The rest of the code already assumes a JCR 2.0 compliant implementation since
> quite a while so the
> [ServiceProvider|https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/ServiceProvider.java#L32C18-L32C33]
> can be refactored that it only takes into account impl specific differences
> (but no longer translations from JCR 2.0 to 1.0)
> Candidates to remove:
> - {{getJcrVersion()}} (always assume JCR 2.0)
> - Remove features purely relying on JCR 2.0 API
> - Maybe also make [Jackrabbit JCR API
> Extensions|https://www.javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/index.html]
> a fix requirement (which version?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-770) Refactor ServiceProvider to no longer cover JCR 2.0 vs 1.0 differences
Konrad Windszus created JCRVLT-770:
--
Summary: Refactor ServiceProvider to no longer cover JCR 2.0 vs
1.0 differences
Key: JCRVLT-770
URL: https://issues.apache.org/jira/browse/JCRVLT-770
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Konrad Windszus
The rest of the code already assumes a JCR 2.0 compliant implementation since
quite a while so the
[ServiceProvider|https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/ServiceProvider.java#L32C18-L32C33]
can be refactored that it only takes into account impl specific differences
(but no longer translations from JCR 2.0 to 1.0)
Candidates to remove:
- {{getJcrVersion()}} (always assume JCR 2.0)
- Remove features purely relying on JCR 2.0 API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-769) mapPackageDependencyToMavenGa does not work on Maven >= 3.6.2
Konrad Windszus created JCRVLT-769: -- Summary: mapPackageDependencyToMavenGa does not work on Maven >= 3.6.2 Key: JCRVLT-769 URL: https://issues.apache.org/jira/browse/JCRVLT-769 Project: Jackrabbit FileVault Issue Type: Bug Components: package maven plugin Reporter: Konrad Windszus Fix For: package-maven-plugin-1.4.0 Due to https://issues.apache.org/jira/browse/MNG-8192 the parameter [mapPackageDependencyToMavenGa|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#mapPackageDependencyToMavenGa] does no longer work, as Maven does no longer allow Artifacts without a valid version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-767) vlt: potential incorrect identifier comparison
[
https://issues.apache.org/jira/browse/JCRVLT-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872062#comment-17872062
]
Konrad Windszus commented on JCRVLT-767:
Even if {{Node.getIdentifer()}} is always non-null (and returns their path for
non-referencable nodes) I don't see how the overall condition on the if would
be wrong? Are you suggesting that stashing happens too often? I was assuming
that stashing is necessary whenever we set the UUID (as we don't do tricks yet
like removing the mixin to make the property unprotected).
> vlt: potential incorrect identifier comparison
> --
>
> Key: JCRVLT-767
> URL: https://issues.apache.org/jira/browse/JCRVLT-767
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Julian Reschke
>Priority: Minor
>
> In
> https://github.com/apache/jackrabbit-filevault/blob/931ceef98513167af3218b773d9213e123a2f52d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L993-L1007
> {noformat}
> if (identifier.isPresent() &&
> !node.getIdentifier().equals(identifier.get()) &&
> !"rep:root".equals(ni.getPrimaryType().orElse(""))) {
> long startTime = System.currentTimeMillis();
> String previousIdentifier = node.getIdentifier();
> log.debug("Node stashing for {} starting, existing identifier:
> {}, new identifier: {}, import mode: {}",
> node.getPath(), previousIdentifier, identifier.get(),
> importMode);
> {noformat}
> However, Node.getIdentifer() will always be non-null - even for nodes without
> mix:referenceable.
> This means that we go into stashing although we don't have to.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JCRVLT-765) Update to FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-765: -- Assignee: Konrad Windszus > Update to FileVault 3.8.0 > - > > Key: JCRVLT-765 > URL: https://issues.apache.org/jira/browse/JCRVLT-765 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > [https://github.com/apache/jackrabbit-filevault/blob/master/RELEASE-NOTES.txt] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-765) Update to FileVault 3.8.0
[ https://issues.apache.org/jira/browse/JCRVLT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-765. Fix Version/s: package-maven-plugin-1.4.0 Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/commit/48b105bf296d3758e2ac1115577dc3319a231736 > Update to FileVault 3.8.0 > - > > Key: JCRVLT-765 > URL: https://issues.apache.org/jira/browse/JCRVLT-765 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.4.0 > > > [https://github.com/apache/jackrabbit-filevault/blob/master/RELEASE-NOTES.txt] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-765) Update to FileVault 3.8.0
Konrad Windszus created JCRVLT-765: -- Summary: Update to FileVault 3.8.0 Key: JCRVLT-765 URL: https://issues.apache.org/jira/browse/JCRVLT-765 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Reporter: Konrad Windszus [https://github.com/apache/jackrabbit-filevault/blob/master/RELEASE-NOTES.txt] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (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 closed JCRVLT-754. -- > 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.8.0, 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] [Closed] (JCRVLT-739) some ImportIT tests do not close resources
[ https://issues.apache.org/jira/browse/JCRVLT-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-739. -- > some ImportIT tests do not close resources > -- > > Key: JCRVLT-739 > URL: https://issues.apache.org/jira/browse/JCRVLT-739 > Project: Jackrabbit FileVault > Issue Type: Task > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 3.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-762) Log/report node identifiers that cause import to switch to stashing and sysview import, also report on slow stashing progress
[ https://issues.apache.org/jira/browse/JCRVLT-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-762. -- > Log/report node identifiers that cause import to switch to stashing and > sysview import, also report on slow stashing progress > - > > Key: JCRVLT-762 > URL: https://issues.apache.org/jira/browse/JCRVLT-762 > Project: Jackrabbit FileVault > Issue Type: Task > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 3.8.0 > > > It would be useful for debugging to find out what UUIDs did not match when FV > decides to use NodeStashing to overwrite a node with a new UUID. > (for instance, it would be interesting to see whether the UUID values just > flip-flop between two alternatives, or whether they are really "new" each > time) > Reporting on progress would be useful because stashing operations on large > collections can be really slow on Oak's MongoDocumentStore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-751. -- > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Assignee: Konrad Windszus >Priority: Major > Labels: vault > Fix For: 3.8.0 > > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-746) Exclude items are not added to WorkspaceFilter in RCP
[ https://issues.apache.org/jira/browse/JCRVLT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-746. -- > Exclude items are not added to WorkspaceFilter in RCP > - > > Key: JCRVLT-746 > URL: https://issues.apache.org/jira/browse/JCRVLT-746 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: RCP >Affects Versions: 3.7.2 >Reporter: WalterSteiner >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.0 > > > The excludes are not working ATM, see > [https://github.com/apache/jackrabbit-filevault/pull/332/files] for a simple > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-738) CugHandlingIT tests do not close resources
[ https://issues.apache.org/jira/browse/JCRVLT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-738. -- > CugHandlingIT tests do not close resources > -- > > Key: JCRVLT-738 > URL: https://issues.apache.org/jira/browse/JCRVLT-738 > Project: Jackrabbit FileVault > Issue Type: Task > Components: vlt >Affects Versions: 3.7.2 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 3.8.0 > > > ...thus leave test resource around (under Windows). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-728) File handle leak in JcrPackageRegistry.register(File,boolean)
[
https://issues.apache.org/jira/browse/JCRVLT-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-728.
--
> File handle leak in JcrPackageRegistry.register(File,boolean)
> -
>
> Key: JCRVLT-728
> URL: https://issues.apache.org/jira/browse/JCRVLT-728
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Affects Versions: 3.7.2
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.0
>
>
> The {{ZipVaultPackage}} in
> https://github.com/apache/jackrabbit-filevault/blob/4a33498c79eaeb2217f8f9763517ef2c7425bcc0/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L367
> is not closed leading to a file handle leak.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-763) IdConflictPolicy: improve documentation for CREATE_NEW_ID
[ https://issues.apache.org/jira/browse/JCRVLT-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-763. -- > IdConflictPolicy: improve documentation for CREATE_NEW_ID > - > > Key: JCRVLT-763 > URL: https://issues.apache.org/jira/browse/JCRVLT-763 > Project: Jackrabbit FileVault > Issue Type: Task > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 3.8.0 > > > We recently were confused while looking at > IdConflictPolicy.CREATE_NEW_ID > (https://jackrabbit.apache.org/filevault/referenceablenodes.html#Id_Conflict_Policies > and > https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html). > Trouble is, this Enum suggests that it's only relevant when there indeed is > an ID conflict. However, it is mapped to > https://developer.adobe.com/experience-manager/reference-materials/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/ImportUUIDBehavior.html > which also affects nodes where there actually is no ID collision whatsoever. > I believe it would be hard to change the behaviour at this point, so we > should at least improve the documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-730) Unstable IT: VaultSyncServiceImplIT.testAddRemoveFileFromNonVltCheckoutFolder
[
https://issues.apache.org/jira/browse/JCRVLT-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-730.
--
> Unstable IT: VaultSyncServiceImplIT.testAddRemoveFileFromNonVltCheckoutFolder
> -
>
> Key: JCRVLT-730
> URL: https://issues.apache.org/jira/browse/JCRVLT-730
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.0
>
>
> {code}
> 16:52:18.914 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncHandler -
> Sync Once requested: JCR2FS
> 16:52:18.924 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncLog - A
> file:///tmp/junit6534468439393939733/junit3629697623599693036/testroot/
> 16:52:18.926 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncLog - A
> file:///tmp/junit6534468439393939733/junit3629697623599693036/testroot/testfile
> 16:52:18.927 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncResult -
> SyncResult:
> fs=/tmp/junit6534468439393939733/junit3629697623599693036/testroot
> jcr=/testroot ops=UPDATE_FS
> 16:52:18.927 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncResult -
> SyncResult:
> fs=/tmp/junit6534468439393939733/junit3629697623599693036/testroot/testfile
> jcr=/testroot/testfile ops=UPDATE_FS
> 16:52:24.068 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncLog - U
> file:///tmp/junit6534468439393939733/junit3629697623599693036/testroot/testfile
> 16:52:24.069 [Vault Sync Thread] INFO o.a.j.vault.sync.impl.SyncResult -
> SyncResult:
> fs=/tmp/junit6534468439393939733/junit3629697623599693036/testroot/testfile
> jcr=/testroot/testfile ops=UPDATE_FS
> [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 26.54
> s <<< FAILURE! -- in
> org.apache.jackrabbit.vault.sync.impl.VaultSyncServiceImplIT
> [ERROR]
> org.apache.jackrabbit.vault.sync.impl.VaultSyncServiceImplIT.testAddRemoveFileFromNonVltCheckoutFolder
> -- Time elapsed: 20.87 s <<< ERROR!
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.jackrabbit.vault.sync.impl.VaultSyncServiceImplIT
> was not fulfilled within 20 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:954)
> at
> org.apache.jackrabbit.vault.sync.impl.VaultSyncServiceImplIT.testAddRemoveFileFromNonVltCheckoutFolder(VaultSyncServiceImplIT.java:75)
> {code}
> This happens on the Jenkins Ubuntu node with JDK 11 but it seems to be some
> kind of race condition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant
[ https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-742. -- > Stop generating MD5, SHA1 and SHA512 with Ant > - > > Key: JCRVLT-742 > URL: https://issues.apache.org/jira/browse/JCRVLT-742 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Fix For: 3.8.0, package-maven-plugin-1.4.0 > > > Currently there is still manual generation of MD5, SHA1 and SHA512 checksum > via Ant in > https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340 > and > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759. > MD5 and SHA1 should no longer be provided according to > https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 > is automatically created through the ASF parent pom > (https://maven.apache.org/pom/asf/#the-apache-release-profile). > In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the > SHA512 anyways. > Note: This is only about ASF dist not about the checksums used in Maven > repositories which are transparently created by Maven Resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-759) Update to ASF Parent POM 33
[ https://issues.apache.org/jira/browse/JCRVLT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-759. -- > Update to ASF Parent POM 33 > --- > > 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.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-745) Stashing: naming and folder location
[ https://issues.apache.org/jira/browse/JCRVLT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-745. -- > Stashing: naming and folder location > > > Key: JCRVLT-745 > URL: https://issues.apache.org/jira/browse/JCRVLT-745 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 3.8.0 > > > We have seen cases where node stashing failed due to RuntimeExceptions (OOM > or MongoDB issues in Oak). In these cases, the tmp folder is not cleaned up. > If the operation is retried many times, there'll be many of these. > Suggestion: > 1. Do not use the root as default location, > 2. Introduce an intermediary node that makes it clear that this is temp space > created by FileVault. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-737) IdConflictPolicy.LEGACY: Parent node not found when installing a package - improve test coverage
[
https://issues.apache.org/jira/browse/JCRVLT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-737.
--
> IdConflictPolicy.LEGACY: Parent node not found when installing a package -
> improve test coverage
>
>
> Key: JCRVLT-737
> URL: https://issues.apache.org/jira/browse/JCRVLT-737
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.7.2
>Reporter: Timothee Maret
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 3.8.0
>
> Attachments: ReferenceableIdentifiersImportIT.java
>
>
> When importing a resource that already exists at with the same jcr:uuid but
> at a different path, the importer balks with :
>
> {code:java}
> Caused by: javax.jcr.RepositoryException: Some errors occurred while
> installing packages. Please check the logs for details. First exception is
> logged as cause.
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:579)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:151)
> [org.apache.sling.distribution.core:0.6.0.T202209271257-98a9dd5]
> ... 11 common frames omitted
> Caused by: org.apache.jackrabbit.vault.packaging.PackageException: Error
> creating/updating node
> /content/dam/cgc/tenants/apac/documents/unitholder-letter/pds-cgnpau-12012023(au).pdf/jcr:content
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1177)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> ... 12 common frames omitted
> Caused by: java.lang.IllegalStateException: Parent node not found.
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1103)
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
> ... 23 common frames omitted {code}
> After removing the resource from the target repository, re-applying the
> package will succeed.
>
> Configuration of the importer:
> {code:java}
> aclHandling :"MERGE_PRESERVE"
> cugHandling :"OVERWRITE"
> importMode: "REPLACE"
> autoSaveThreshold: 1000 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-761) Allow to get qualified name via NodeContext
[
https://issues.apache.org/jira/browse/JCRVLT-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-761.
--
> Allow to get qualified name via NodeContext
> ---
>
> Key: JCRVLT-761
> URL: https://issues.apache.org/jira/browse/JCRVLT-761
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: validation
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.8.0
>
>
> As validators often include node or property names in their validation
> messages there should be some means to get the [qualified
> name|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form]
> from the {{org.apache.jackrabbit.spi.Name}} used in {{DocViewNode2}} and
> {{DocViewProperty2}}.
> The easiest way is to add a getter method similar to
> https://jackrabbit.apache.org/api/2.20/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getJCRName-org.apache.jackrabbit.spi.Name-
> to the {{NodeContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (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
]
Konrad Windszus closed JCRVLT-747.
--
> 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.8.0
>
>
> 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] [Closed] (JCRVLT-760) release check fails
[
https://issues.apache.org/jira/browse/JCRVLT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-760.
--
> release check fails
> ---
>
> Key: JCRVLT-760
> URL: https://issues.apache.org/jira/browse/JCRVLT-760
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: Julian Reschke
> Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.8.0
>
> Attachments: JCRVLT-760-check-release-v1.patch
>
>
> As per https://jackrabbit.apache.org/filevault/howto_release.html I tried
> {noformat}
> sh check-release.sh filevault 3.7.4
> {noformat}
> but that fails with:
> {noformat}
> [INFO]Unzipping jackrabbit-filevault-3.7.4-source-release.zip...
> Cleaning .gitignore from zip
> Cleaning .gitattributes from zip
> Cleaning .flattened-pom.xml from zip
> [INFO]Comparing sources...
> [INFO]
> Only in ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4:
> .asf.yaml
> Only in ./target/jackrabbit-filevault-3.7.4/zip/jackrabbit-filevault-3.7.4:
> DEPENDENCIES
> Only in ./target/jackrabbit-filevault-3.7.4/zip/jackrabbit-filevault-3.7.4:
> LICENSE
> Only in ./target/jackrabbit-filevault-3.7.4/zip/jackrabbit-filevault-3.7.4:
> NOTICE
> Only in ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4:
> target-osgi-environment
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-core:
> max-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-core:
> min-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-rcp:
> max-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-rcp:
> min-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-sync:
> min-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-validation:
> max-target.bndrun
> Only in
> ./target/jackrabbit-filevault-3.7.4/scm/jackrabbit-filevault-3.7.4/vault-validation:
> min-target.bndrun
> [ERROR] NOT OK: Tagged sources are different from those in the archive
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT] [VOTE] Release Apache Jackrabbit FileVault 3.8.0
Hi, The vote passes with 4 binding votes from Julian, Manfred, Jörg and myself. Thanks for voting. I'll push the release out. Regards Konrad > On 1. Aug 2024, at 09:38, Konrad Windszus wrote: > > Hi, > A candidate for the Jackrabbit FileVault 3.8.0 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.8.0/ > > The release candidate is a zip archive of the sources in: > > https://github.com/apache/jackrabbit-filevault/tree/jackrabbit-filevault-3.8.0/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314920&version=12353788 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault 3.8.0 > (leveraging the script from > https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh) > > A staged Maven repository is available for review at: > > https://repository.apache.org/content/repositories/orgapachejackrabbit-1689 > > Please vote on releasing this package as Apache Jackrabbit FileVault 3.8.0. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault 3.8.0 > [ ] -1 Do not release this package because... > > Regards, > Konrad >
[jira] [Commented] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871234#comment-17871234
]
Konrad Windszus commented on JCR-5095:
--
I added a temporary Jenkins build at
[https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-jcr5095/]
targetting branch
https://github.com/apache/jackrabbit/tree/bugfix/token-race-condition
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871141#comment-17871141
]
Konrad Windszus commented on JCR-5095:
--
My assumption is that
https://github.com/apache/jackrabbit/blob/a4a3c7c38b1159472110b80d087549b146eeb54a/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenProvider.java#L147
may fail under heavy concurrency. The token node name is created from Calendar
populated from the epoch (with milliseconds), e.g.
{color:#00}2024-08-05T20:10:42.826+02:00.{color}
Under heavy concurrency the same node name may be used for different login
tokens which may lead to same-name siblings. The {{TokenInfoImpl}} uses only
the (non-unique) tokenPath to change expiry data and remove it (in
https://github.com/apache/jackrabbit/blob/a4a3c7c38b1159472110b80d087549b146eeb54a/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenProvider.java#L449).
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1787#comment-1787
]
Konrad Windszus commented on JCR-5095:
--
With improved logging from
https://github.com/apache/jackrabbit/commit/a4a3c7c38b1159472110b80d087549b146eeb54a
I see
{code:java}
[ERROR] Tests run: 38, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 30.85
s <<< FAILURE! -- in
org.apache.jackrabbit.core.security.authentication.token.TestAll
[ERROR]
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces
-- Time elapsed: 15.57 s <<< ERROR!
java.lang.IllegalStateException: Thread Thread-177 (id 396) failed
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.lambda$assertThreadExecutionSucceeds$0(TokenBasedLoginTest.java:400)
at java.base/java.util.Optional.map(Optional.java:260)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.assertThreadExecutionSucceeds(TokenBasedLoginTest.java:400)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.assertParallelExecutionSucceeds(TokenBasedLoginTest.java:374)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces(TokenBasedLoginTest.java:324)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
at junit.framework.TestCase.run(TestCase.java:130)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
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)
Caused by:
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest$UncheckedRepositoryException:
javax.jcr.LoginException: Failed to commit: failed to build path of
cfa0ab83-014c-4f38-a8e3-bf967e153462: 9429a816-3771-4f63-9004-5a7c2c71ba8f has
no child entry for cfa0ab83-014c-4f38-a8e3-bf967e153462
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest$4.run(TokenBasedLoginTest.java:369)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: javax.jcr.LoginException: Failed to commit: failed to build path of
cfa0ab83-014c-4f38-a8e3-bf967e153462: 9429a816-3771-4f63-9004-5a7c2c71ba8f has
no child entry for cfa0ab83-014c-4f38-a8e3-bf967e153462
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1528)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest$3.run(TokenBasedLoginTest.java:334)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest$4.run(TokenBasedLoginTest.java:367)
... 1 more
Caused by: javax.security.auth.login.LoginException: Failed to commit: failed
to build path of cfa0ab83-014c-4f38-a8e3-bf967e153462:
9429a816-3771-4f63-9004-5a7c2c71ba8f has no child entry for
cfa0ab83-014c-4f38-a8e3-bf967e153462
at
org.apache.jackrabbit.core.security.authentication.DefaultLoginModule.commit(DefaultLoginModul
[jira] [Comment Edited] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871067#comment-17871067
]
Konrad Windszus edited comment on JCR-5095 at 8/5/24 1:27 PM:
--
The tests themselves are executed in a single Java process in a sequential
fashion, so it rather seems to depend on the [order of tests being
executed|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runorder]
and probably missing calls to clean up the repository after test execution (as
the repo is being reused among all tests).
was (Author: kwin):
The tests themselves are executed in a single Java process in a sequential
fashion, so it rather seems to depend on the order of tests being executed and
probably missing calls to clean up the repository after test execution (as the
repo is being reused among all tests).
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871067#comment-17871067
]
Konrad Windszus commented on JCR-5095:
--
The tests themselves are executed in a single Java process in a sequential
fashion, so it rather seems to depend on the order of tests being executed and
probably missing calls to clean up the repository after test execution (as the
repo is being reused among all tests).
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871047#comment-17871047
]
Konrad Windszus commented on JCR-5095:
--
Also it seems to be more likely to appear with Java 22. Need to investigate how
the {{RepositoryHelper}} can deal with multi-threading and how test are being
executed with m-surefire-p.
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5093) jcr2spi: get rid of Commons IO dependency
[ https://issues.apache.org/jira/browse/JCR-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCR-5093: - Fix Version/s: 2.23.1 > jcr2spi: get rid of Commons IO dependency > - > > Key: JCR-5093 > URL: https://issues.apache.org/jira/browse/JCR-5093 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr2spi > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Labels: candidate_jackrabbit_2.22 > Fix For: 2.24, 2.23.1 > > > With relying on Java 11 API there is no longer the need to still depend on > Commons IO. Most helpers can be easily replaced by Java 11 API nowadays. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5095) TokenBasedLoginTest is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5095:
-
Summary: TokenBasedLoginTest is flaky (was:
TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky)
> TokenBasedLoginTest is flaky
>
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
> Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> {code:java}
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> – Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
> at junit.framework.TestCase.run(TestCase.java:130)
> at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
> at junit.framework.TestSuite.runTest(TestSuite.java:241)
> at junit.framework.TestSuite.run(TestSuite.java:236)
> 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){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5095) TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5095:
-
Description:
The Jenkins build is failing sometimes due to that
([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
The logs shows
{code:java}
[ERROR]
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
– Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
javax.jcr.LoginException: Failed to commit: failed to build path of
b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd has
no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
at junit.framework.TestCase.run(TestCase.java:130)
at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
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){code}
was:
The Jenkins build is failing sometimes due to that
([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
The logs shows
[ERROR]
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
-- Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
javax.jcr.LoginException: Failed to commit: failed to build path of
b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd has
no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
at junit.framework.TestCase.run(TestCase.java:130)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
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.ja
[jira] [Updated] (JCR-5095) TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky
[
https://issues.apache.org/jira/browse/JCR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5095:
-
Description:
The Jenkins build is failing sometimes due to that
([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
The logs shows
[ERROR]
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
-- Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
javax.jcr.LoginException: Failed to commit: failed to build path of
b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd has
no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at
org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
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 org.apache.jackrabbit.test.JCRTestResult.run(JCRTestResult.java:75)
at junit.framework.TestCase.run(TestCase.java:130)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:476)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
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)
was:
The Jenkins build is failing sometimes due to that
([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
The logs shows
{{[ERROR] Failures: [ERROR]
TokenBasedLoginTest>AbstractJCRTest.run:476->testConcurrentLoginDifferentWorkspaces:416
javax.jcr.LoginException: Failed to commit: failed to build path of
596e2bc1-59a1-479b-9b09-b01c1c85892e: 50f0d215-ecb4-4eab-8750-bc35c9505085 has
no child entry for 596e2bc1-59a1-479b-9b09-b01c1c85892e}}
> TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky
> ---
>
> Key: JCR-5095
> URL: https://issues.apache.org/jira/browse/JCR-5095
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Reporter: Konrad Windszus
>Priority: Major
>
> The Jenkins build is failing sometimes due to that
> ([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
> The logs shows
> [ERROR]
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin
> -- Time elapsed: 2.463 s <<< FAILURE!junit.framework.AssertionFailedError:
> javax.jcr.LoginException: Failed to commit: failed to build path of
> b7a136a5-5247-460d-bd74-4e191872ca92: 18765f8a-895a-49c4-831b-dc5119faaacd
> has no child entry for b7a136a5-5247-460d-bd74-4e191872ca92
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:223)
> at
> org.apache.jackrabbit.core.security.authentication.token.TokenBasedLoginTest.testConcurrentLogin(TokenBasedLoginTest.java:275)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at junit.framework.TestCase.runTest(TestCase.java:177)
> at junit.framework.TestCase.runBare(TestCase.java:142)
> at junit.framework.TestResult
[jira] [Created] (JCR-5095) TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky
Konrad Windszus created JCR-5095:
Summary:
TokenBasedLoginTest.testConcurrentLoginDifferentWorkspaces is flaky
Key: JCR-5095
URL: https://issues.apache.org/jira/browse/JCR-5095
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: core
Reporter: Konrad Windszus
The Jenkins build is failing sometimes due to that
([https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/).]
The logs shows
{{[ERROR] Failures: [ERROR]
TokenBasedLoginTest>AbstractJCRTest.run:476->testConcurrentLoginDifferentWorkspaces:416
javax.jcr.LoginException: Failed to commit: failed to build path of
596e2bc1-59a1-479b-9b09-b01c1c85892e: 50f0d215-ecb4-4eab-8750-bc35c9505085 has
no child entry for 596e2bc1-59a1-479b-9b09-b01c1c85892e}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCR-5093) jcr2spi: get rid of Commons IO dependency
[ https://issues.apache.org/jira/browse/JCR-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCR-5093. -- Fix Version/s: 2.24 Resolution: Fixed Fixed in [https://github.com/apache/jackrabbit/commit/bfa0187b685fbdc00b05a14ffb034f4ef6ee520e] (trunk) > jcr2spi: get rid of Commons IO dependency > - > > Key: JCR-5093 > URL: https://issues.apache.org/jira/browse/JCR-5093 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr2spi > Reporter: Konrad Windszus > Assignee: Konrad Windszus >Priority: Major > Labels: candidate_jackrabbit_2.22 > Fix For: 2.24 > > > With relying on Java 11 API there is no longer the need to still depend on > Commons IO. Most helpers can be easily replaced by Java 11 API nowadays. -- This message was sent by Atlassian Jira (v8.20.10#820010)
