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