[GitHub] [jackrabbit-oak] reschke opened a new pull request, #1038: OAK-10323: remove all remaining references of native Guava
reschke opened a new pull request, #1038: URL: https://github.com/apache/jackrabbit-oak/pull/1038 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JCRVLT-713) filevault-package-maven-plugin wrongly reports duplicate files for same path
[ https://issues.apache.org/jira/browse/JCRVLT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747128#comment-17747128 ] Roy Teeuwen commented on JCRVLT-713: [~kwin] of course! I created the most basic example I could think of: https://github.com/royteeuwen/jcrvlt-713-example > filevault-package-maven-plugin wrongly reports duplicate files for same path > > > Key: JCRVLT-713 > URL: https://issues.apache.org/jira/browse/JCRVLT-713 > Project: Jackrabbit FileVault > Issue Type: Bug >Reporter: Roy Teeuwen >Priority: Major > > I have the following setup: > * a maven plugin generates css files from scss files in the > src/main/content/jcr_root folder, add's them to target/vault-work/jcr_root/... > * maven resources plugin adds all the other files that are in the > src/main/content/jcr_root to the target/vault-work/jcr_root > * filevault-package-maven-plugin creates the package, with as settings > jcrRootSourceDirectory = > ${project.build.directory}/vault-work/jcr_root > When doing this, the filevault plugin throws errors on duplicate files, for > example: > {code:java} > Found duplicate file 'jcr_root/apps/author/websites/general/css/_header.scss' > from sources > 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss' > and > 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss'{code} > > As you can see, this is two times the same path. > I'm not sure if this is fixable through different plugin configuration? I can > make a PR that checks if both paths are the same before logging as duplicate > file, but that just sounds like a workaround instead of a correct fix > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] reschke merged pull request #1037: OAK-10322: oak-core: remove Guava from public API
reschke merged PR #1037: URL: https://github.com/apache/jackrabbit-oak/pull/1037 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JCRVLT-713) filevault-package-maven-plugin wrongly reports duplicate files for same path
[ https://issues.apache.org/jira/browse/JCRVLT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747014#comment-17747014 ] Konrad Windszus commented on JCRVLT-713: [~royteeuwen] Can you share an example project on GitHub which allows me to reproduce? In general copying from src to target/vault-work is not necessary as packaging uses the original sources in case no filtering is done. > filevault-package-maven-plugin wrongly reports duplicate files for same path > > > Key: JCRVLT-713 > URL: https://issues.apache.org/jira/browse/JCRVLT-713 > Project: Jackrabbit FileVault > Issue Type: Bug >Reporter: Roy Teeuwen >Priority: Major > > I have the following setup: > * a maven plugin generates css files from scss files in the > src/main/content/jcr_root folder, add's them to target/vault-work/jcr_root/... > * maven resources plugin adds all the other files that are in the > src/main/content/jcr_root to the target/vault-work/jcr_root > * filevault-package-maven-plugin creates the package, with as settings > jcrRootSourceDirectory = > ${project.build.directory}/vault-work/jcr_root > When doing this, the filevault plugin throws errors on duplicate files, for > example: > {code:java} > Found duplicate file 'jcr_root/apps/author/websites/general/css/_header.scss' > from sources > 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss' > and > 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss'{code} > > As you can see, this is two times the same path. > I'm not sure if this is fixable through different plugin configuration? I can > make a PR that checks if both paths are the same before logging as duplicate > file, but that just sounds like a workaround instead of a correct fix > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] reschke opened a new pull request, #1037: OAK-10322: oak-core: remove Guava from public API
reschke opened a new pull request, #1037: URL: https://github.com/apache/jackrabbit-oak/pull/1037 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
CVE-2023-37895: Apache Jackrabbit RMI access can lead to RCE
Severity: critical Affected versions: - Apache Jackrabbit Webapp (jackrabbit-webapp) 2.21.0 before 2.21.18 - Apache Jackrabbit Webapp (jackrabbit-webapp) 1.0.0 before 2.20.11 - Apache Jackrabbit Standalone (jackrabbit-standalone and jackrabbit-standalone-components) 2.21.0 before 2.21.18 - Apache Jackrabbit Standalone (jackrabbit-standalone and jackrabbit-standalone-components) 1.0.0 before 2.20.11 Description: Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component "commons-beanutils", which contains a class that can be used for remote code execution over RMI. Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore. In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases. How to check whether RMI support is enabledRMI support can be over an RMI-specific TCP port, and over an HTTP binding. Both are by default enabled in Jackrabbit webapp/standalone. The native RMI protocol by default uses port 1099. To check whether it is enabled, tools like "netstat" can be used to check. RMI-over-HTTP in Jackrabbit by default uses the path "/rmi". So when running standalone on port 8080, check whether an HTTP GET request on localhost:8080/rmi returns 404 (not enabled) or 200 (enabled). Note that the HTTP path may be different when the webapp is deployed in a container as non-root context, in which case the prefix is under the user's control. Turning off RMIFind web.xml (either in JAR/WAR file or in unpacked web application folder), and remove the declaration and the mapping definition for the RemoteBindingServlet: RMI org.apache.jackrabbit.servlet.remote.RemoteBindingServlet RMI /rmi Find the bootstrap.properties file (in $REPOSITORY_HOME), and set rmi.enabled=false and also remove rmi.host rmi.port rmi.url-pattern If there is no file named bootstrap.properties in $REPOSITORY_HOME, it is located somewhere in the classpath. In this case, place a copy in $REPOSITORY_HOME and modify it as explained. Credit: Siebene@ (reporter) Michael Dürig (other) Manfred Baedke (other) References: https://lists.apache.org/list.html?us...@jackrabbit.apache.org https://jackrabbit.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-37895 Timeline: 2023-06-30: Reported 2023-07-20: Release vote for unstable branch with fix 2023-07-20: Release vote for stable branch with fix 2023-07-24: unstable branch (2.21.18) released 2023-07-24: stable branch (2.20.11) released
[GitHub] [jackrabbit-oak] anchela merged pull request #1034: OAK-10318 : Improve AutoMembershipPrincipals#isInheritedMember
anchela merged PR #1034: URL: https://github.com/apache/jackrabbit-oak/pull/1034 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] anchela commented on pull request #1034: OAK-10318 : Improve AutoMembershipPrincipals#isInheritedMember
anchela commented on PR #1034: URL: https://github.com/apache/jackrabbit-oak/pull/1034#issuecomment-1649743520 build failure: Error: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on project oak-store-document: There are test failures, which seem unrelated to my changes. the ci failed on oak-run which also is unrelated. i am going to merge it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] fabriziofortino commented on a diff in pull request #1035: OAK-10365: introduce mapping version in elastic index definition
fabriziofortino commented on code in PR #1035: URL: https://github.com/apache/jackrabbit-oak/pull/1035#discussion_r1273447221 ## oak-search-elastic/src/test/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticIndexTest.java: ## @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.jackrabbit.oak.plugins.index.elastic.index; + +import org.apache.jackrabbit.oak.api.Tree; +import org.apache.jackrabbit.oak.plugins.index.elastic.ElasticAbstractQueryTest; +import org.apache.jackrabbit.oak.plugins.index.search.util.IndexDefinitionBuilder; +import org.junit.Test; + +import java.util.UUID; + +import static org.junit.Assert.assertEquals; + +public class ElasticIndexTest extends ElasticAbstractQueryTest { + +@Test +public void indexStoresMappingVersion() throws Exception { +IndexDefinitionBuilder builder = createIndex("a").noAsync(); +builder.indexRule("nt:base").property("a").propertyIndex(); +Tree index = setIndex(UUID.randomUUID().toString(), builder); +root.commit(); + +assertEventually(() -> assertEquals(ElasticIndexHelper.MAPPING_VERSION, +getElasticIndexDefinition(index).getMappingVersion())); +} Review Comment: As in the comment above, the version is internal and cannot be configured in the index definition. In this test we just need to test the mapping version gets stored and is equal to the current mapping version (`ElasticIndexHelper.MAPPING_VERSION`). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] fabriziofortino commented on a diff in pull request #1035: OAK-10365: introduce mapping version in elastic index definition
fabriziofortino commented on code in PR #1035: URL: https://github.com/apache/jackrabbit-oak/pull/1035#discussion_r1273445678 ## oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticIndexDefinition.java: ## @@ -269,6 +274,14 @@ public boolean analyzerConfigSplitOnNumerics() { return getOptionalValue(analyzersTree, SPLIT_ON_NUMERICS, false); } +/** + * Returns the mapping version for this index definition. + * If the version is not specified, the default value is {@code 1.0.0}. + */ +public String getMappingVersion() { +return getOptionalValue(definition, PROP_INDEX_MAPPING_VERSION, "1.0.0"); +} Review Comment: The mapping version is internal and cannot be changed in the index definition (it's stored in a hidden property). If the index definition does not have a version, we return the base version currently set as `1.0.0`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JCRVLT-713) filevault-package-maven-plugin wrongly reports duplicate files for same path
Roy Teeuwen created JCRVLT-713: -- Summary: filevault-package-maven-plugin wrongly reports duplicate files for same path Key: JCRVLT-713 URL: https://issues.apache.org/jira/browse/JCRVLT-713 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Roy Teeuwen I have the following setup: * a maven plugin generates css files from scss files in the src/main/content/jcr_root folder, add's them to target/vault-work/jcr_root/... * maven resources plugin adds all the other files that are in the src/main/content/jcr_root to the target/vault-work/jcr_root * filevault-package-maven-plugin creates the package, with as settings jcrRootSourceDirectory = ${project.build.directory}/vault-work/jcr_root When doing this, the filevault plugin throws errors on duplicate files, for example: {code:java} Found duplicate file 'jcr_root/apps/author/websites/general/css/_header.scss' from sources 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss' and 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss'{code} As you can see, this is two times the same path. I'm not sure if this is fixable through different plugin configuration? I can make a PR that checks if both paths are the same before logging as duplicate file, but that just sounds like a workaround instead of a correct fix -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746932#comment-17746932 ] Manfred Baedke commented on JCR-4957: - ??Good to know but it makes it near impossible to use GitHub's dependabot or Maven's display dependency updates plugin; maybe the version should have an "-unstable" or "-M" version postfix to make it obvious it should not be used as a dependency.?? At least for the version plugin it should be possible to create an exclusion rule based on RegEx. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746930#comment-17746930 ] Gary D. Gregory commented on JCR-4957: -- Hi [~reschke] I don't remember what I had for breakfast either ;-) I guess I'm glad I'm consistent! :-) > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746924#comment-17746924 ] Julian Reschke commented on JCR-4957: - FWIW: https://issues.apache.org/jira/browse/VFS-756?focusedCommentId=17165257&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17165257 > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746900#comment-17746900 ] Gary D. Gregory commented on JCR-4957: -- Good to know but it makes it near impossible to use GitHub's dependabot or Maven's display dependency updates plugin; maybe the version should have an "-unstable" or "-M" version postfix to make it obvious it should not be used as a dependency. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746890#comment-17746890 ] Manfred Baedke commented on JCR-4957: - Find attached a patch that passes a baseline check. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4958) Decide what jackrabbit-standalone-components should expose as public API
Manfred Baedke created JCR-4958: --- Summary: Decide what jackrabbit-standalone-components should expose as public API Key: JCR-4958 URL: https://issues.apache.org/jira/browse/JCR-4958 Project: Jackrabbit Content Repository Issue Type: Task Components: jackrabbit-standalone-components Reporter: Manfred Baedke Apache Commons VFS uses public methods of Classes that are part of jackrabbit-standalone-components (for testing purposes), but the baseline check is disabled here. We should decide about the public API we want to expose and introduce a baseline check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4957: Attachment: jcr-4957.patch Status: Patch Available (was: Open) > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4957: Attachment: (was: jcr-4957.patch) > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4957: Status: Open (was: Patch Available) > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] nfsantos commented on a diff in pull request #1035: OAK-10365: introduce mapping version in elastic index definition
nfsantos commented on code in PR #1035: URL: https://github.com/apache/jackrabbit-oak/pull/1035#discussion_r1273270397 ## oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticIndexDefinition.java: ## @@ -269,6 +274,14 @@ public boolean analyzerConfigSplitOnNumerics() { return getOptionalValue(analyzersTree, SPLIT_ON_NUMERICS, false); } +/** + * Returns the mapping version for this index definition. + * If the version is not specified, the default value is {@code 1.0.0}. + */ +public String getMappingVersion() { +return getOptionalValue(definition, PROP_INDEX_MAPPING_VERSION, "1.0.0"); +} Review Comment: Shouldn't the default value be a clearly invalid version, like 0.0.0? Because we will assume that 1.0.0 is a valid version, so it can create confusion in cases where the index is missing a version, we might assume wrongly that it has a version. ## oak-search-elastic/src/test/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticIndexTest.java: ## @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.jackrabbit.oak.plugins.index.elastic.index; + +import org.apache.jackrabbit.oak.api.Tree; +import org.apache.jackrabbit.oak.plugins.index.elastic.ElasticAbstractQueryTest; +import org.apache.jackrabbit.oak.plugins.index.search.util.IndexDefinitionBuilder; +import org.junit.Test; + +import java.util.UUID; + +import static org.junit.Assert.assertEquals; + +public class ElasticIndexTest extends ElasticAbstractQueryTest { + +@Test +public void indexStoresMappingVersion() throws Exception { +IndexDefinitionBuilder builder = createIndex("a").noAsync(); +builder.indexRule("nt:base").property("a").propertyIndex(); +Tree index = setIndex(UUID.randomUUID().toString(), builder); +root.commit(); + +assertEventually(() -> assertEquals(ElasticIndexHelper.MAPPING_VERSION, +getElasticIndexDefinition(index).getMappingVersion())); +} Review Comment: It is missing a test that sets the mapping version and checks that it returns the version that we set. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-4957: Attachment: jcr-4957.patch Status: Patch Available (was: In Progress) > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > Attachments: jcr-4957.patch > > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746825#comment-17746825 ] Manfred Baedke edited comment on JCR-4957 at 7/25/23 8:15 AM: -- [~reschke] ??I really wasn't aware of this kind of usage.?? Me neither, which is unfortunate, because it's explicitly mentioned in the JavaDoc. It should be easy to bring the old API back. ??If standalone-components is a public API, it should have OSGi annotations to the baseline check manages API stability.?? Yes, we should create a separate issue for that. ??the main method really really is an aspect of the demo project?? Yes. The signature or semantics of the main method didn't change, though. was (Author: baedke): [~reschke] ??I really wasn't aware of this kind of usage.?? Me neither, which is unfortunate, because it's explicitly mentioned in the JavaDoc. It should be easy to bring the old API back. ??If standalone-components is a public API, it should have OSGi annotations to the baseline check manages API stability.?? Yes, we should create a separate issue for that. ??the main method really really is an aspect of the demo project?? Yes. The main method didn't change, though. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746825#comment-17746825 ] Manfred Baedke edited comment on JCR-4957 at 7/25/23 8:14 AM: -- [~reschke] ??I really wasn't aware of this kind of usage.?? Me neither, which is unfortunate, because it's explicitly mentioned in the JavaDoc. It should be easy to bring the old API back. ??If standalone-components is a public API, it should have OSGi annotations to the baseline check manages API stability.?? Yes, we should create a separate issue for that. ??the main method really really is an aspect of the demo project?? Yes. The main method didn't change, though. was (Author: baedke): [~reschke] ??I really wasn't aware of this kind of usage.?? Me neither, which is unfortunate, because it's explicitly mentioned in the JavaDoc. It should be easy to bring the old API back. ??If standalone-components is a public API, it should have OSGi annotations to the baseline check manages API stability.?? Yes, we should create a separate issue for that. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] fabriziofortino merged pull request #1035: OAK-10365: introduce mapping version in elastic index definition
fabriziofortino merged PR #1035: URL: https://github.com/apache/jackrabbit-oak/pull/1035 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746822#comment-17746822 ] Julian Reschke edited comment on JCR-4957 at 7/25/23 8:12 AM: -- If standalone-components is a public API, it shoukd have OSGi annotations to the baseline check manages API stability. Also, as far as I can tell, the main method really really is an aspect of the demo project; and if I read correctly, it's only used in VFS test cases? was (Author: reschke): If standalone-components is a public API, it shoukd have OSGi annotations to the baseline check manages API stability. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746825#comment-17746825 ] Manfred Baedke commented on JCR-4957: - [~reschke] ??I really wasn't aware of this kind of usage.?? Me neither, which is unfortunate, because it's explicitly mentioned in the JavaDoc. It should be easy to bring the old API back. ??If standalone-components is a public API, it should have OSGi annotations to the baseline check manages API stability.?? Yes, we should create a separate issue for that. > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[ https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned JCR-4957: --- Assignee: Manfred Baedke > Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17 > -- > > Key: JCR-4957 > URL: https://issues.apache.org/jira/browse/JCR-4957 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.21.18 >Reporter: Gary D. Gregory >Assignee: Manfred Baedke >Priority: Major > > We see this break in Apache Commons VFS when trying to update from 2.21.17 to > 2.21.18: > {quote}[INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27] > incompatible types: java.lang.String[] cannot be converted to > org.apache.commons.cli.CommandLine > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18] > cannot find symbol > symbol: constructor (java.lang.String[]) > [ERROR] > /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15] > method run in class org.apache.jackrabbit.standalone.Main cannot be applied > to given types; > required: java.io.File,java.io.File,java.io.File > found: no arguments > reason: actual and formal argument lists differ in length > [INFO] 3 errors > {quote} > Breaking BC in a non-major release should not be allowed IMO. -- This message was sent by Atlassian Jira (v8.20.10#820010)