[jira] [Commented] (SOLR-18092) ExternalPaths clinit errors when using test-framework in downstream projects
[
https://issues.apache.org/jira/browse/SOLR-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18074481#comment-18074481
]
ASF subversion and git services commented on SOLR-18092:
Commit 4f4bf3e713a983262a8ff03fcf1c38ef7c8a045e in solr's branch
refs/heads/branch_10x from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=4f4bf3e713a ]
SOLR-18092: fix solr-test-framework for 3rd party -- ExternalPaths NPE (#4225)
Co-authored-by: David Smiley
> ExternalPaths clinit errors when using test-framework in downstream projects
>
>
> Key: SOLR-18092
> URL: https://issues.apache.org/jira/browse/SOLR-18092
> Project: Solr
> Issue Type: Bug
>Affects Versions: 10.0
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr 10 (or maybe 9.10?) broke the ability to use Solr's {{test-framework}}
> in downstream projects to develop plugins, due to changes in the way
> {{ExternalPaths.SOURCE_HOME}} is initialized.
> The docs for this variable say the variable will be {{null}} in situations
> such as "the current context is a client code base using the test framework"
> – but the {{determineSourceHome()}} method used to initialize this variable
> was changed to throw an exception instead of returning null.
>
> Because this method is called on class loading, and because {{ExternalPaths}}
> is used pervasively in the {{test-framework}} code, there is no "code change"
> downstream projects can make to resolve these exceptions.
> Instead the one workaround I have identified for this back-compat break is
> for downstream packages to add some empty dummy directories and files to
> their test classpaths...
> {noformat}
> ./src/test/resources/solr/conf/
> ./src/test/resources/solr/test-framework/build.gradle
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-18092) ExternalPaths clinit errors when using test-framework in downstream projects
[
https://issues.apache.org/jira/browse/SOLR-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072985#comment-18072985
]
ASF subversion and git services commented on SOLR-18092:
Commit 1da74ce73a6dffd78568b9f17b4be2dbe307c10a in solr's branch
refs/heads/main from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=1da74ce73a6 ]
SOLR-18092: fix solr-test-framework for 3rd party -- ExternalPaths NPE (#4225)
Co-authored-by: David Smiley
> ExternalPaths clinit errors when using test-framework in downstream projects
>
>
> Key: SOLR-18092
> URL: https://issues.apache.org/jira/browse/SOLR-18092
> Project: Solr
> Issue Type: Bug
>Affects Versions: 10.0
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr 10 (or maybe 9.10?) broke the ability to use Solr's {{test-framework}}
> in downstream projects to develop plugins, due to changes in the way
> {{ExternalPaths.SOURCE_HOME}} is initialized.
> The docs for this variable say the variable will be {{null}} in situations
> such as "the current context is a client code base using the test framework"
> – but the {{determineSourceHome()}} method used to initialize this variable
> was changed to throw an exception instead of returning null.
>
> Because this method is called on class loading, and because {{ExternalPaths}}
> is used pervasively in the {{test-framework}} code, there is no "code change"
> downstream projects can make to resolve these exceptions.
> Instead the one workaround I have identified for this back-compat break is
> for downstream packages to add some empty dummy directories and files to
> their test classpaths...
> {noformat}
> ./src/test/resources/solr/conf/
> ./src/test/resources/solr/test-framework/build.gradle
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-18092) ExternalPaths clinit errors when using test-framework in downstream projects
[
https://issues.apache.org/jira/browse/SOLR-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18067779#comment-18067779
]
David Smiley commented on SOLR-18092:
-
There's a linked PR fixing the issue. CHANGELOG updated. The fact that it
works is testable via a PR on SOLR-18069
> ExternalPaths clinit errors when using test-framework in downstream projects
>
>
> Key: SOLR-18092
> URL: https://issues.apache.org/jira/browse/SOLR-18092
> Project: Solr
> Issue Type: Bug
>Affects Versions: 10.0
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Solr 10 (or maybe 9.10?) broke the ability to use Solr's {{test-framework}}
> in downstream projects to develop plugins, due to changes in the way
> {{ExternalPaths.SOURCE_HOME}} is initialized.
> The docs for this variable say the variable will be {{null}} in situations
> such as "the current context is a client code base using the test framework"
> – but the {{determineSourceHome()}} method used to initialize this variable
> was changed to throw an exception instead of returning null.
>
> Because this method is called on class loading, and because {{ExternalPaths}}
> is used pervasively in the {{test-framework}} code, there is no "code change"
> downstream projects can make to resolve these exceptions.
> Instead the one workaround I have identified for this back-compat break is
> for downstream packages to add some empty dummy directories and files to
> their test classpaths...
> {noformat}
> ./src/test/resources/solr/conf/
> ./src/test/resources/solr/test-framework/build.gradle
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-18092) ExternalPaths clinit errors when using test-framework in downstream projects
[
https://issues.apache.org/jira/browse/SOLR-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055017#comment-18055017
]
David Smiley commented on SOLR-18092:
-
I wish we had some sort of integration test / CI job to catch this!
> ExternalPaths clinit errors when using test-framework in downstream projects
>
>
> Key: SOLR-18092
> URL: https://issues.apache.org/jira/browse/SOLR-18092
> Project: Solr
> Issue Type: Bug
>Affects Versions: 10.0
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Solr 10 (or maybe 9.10?) broke the ability to use Solr's {{test-framework}}
> in downstream projects to develop plugins, due to changes in the way
> {{ExternalPaths.SOURCE_HOME}} is initialized.
> The docs for this variable say the variable will be {{null}} in situations
> such as "the current context is a client code base using the test framework"
> – but the {{determineSourceHome()}} method used to initialize this variable
> was changed to throw an exception instead of returning null.
>
> Because this method is called on class loading, and because {{ExternalPaths}}
> is used pervasively in the {{test-framework}} code, there is no "code change"
> downstream projects can make to resolve these exceptions.
> Instead the one workaround I have identified for this back-compat break is
> for downstream packages to add some empty dummy directories and files to
> their test classpaths...
> {noformat}
> ./src/test/resources/solr/conf/
> ./src/test/resources/solr/test-framework/build.gradle
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-18092) ExternalPaths clinit errors when using test-framework in downstream projects
[
https://issues.apache.org/jira/browse/SOLR-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054899#comment-18054899
]
Chris M. Hostetter commented on SOLR-18092:
---
This appears to have been broken by an unnecessary / off-topic logic change
made as part of SOLR-17619
{noformat}
$ git show 27eb9dc061b0314cc3235c588ff66c9fb69c526a --
./solr/test-framework/src/java/org/apache/solr/util/ExternalPaths.java | cat
commit 27eb9dc061b0314cc3235c588ff66c9fb69c526a
Author: David Smiley
AuthorDate: 2025-10-22 13:27:30 -0400
Commit: Jan Høydahl
CommitDate: 2025-10-22 19:40:06 +0200
SOLR-17619 Use logchange for changelog management (#3044)
Co-authored-by: David Smiley
(cherry picked from commit 9d0a652e5a58e542d305cbcbc6cb7c2d701449a6)
diff --git
a/solr/test-framework/src/java/org/apache/solr/util/ExternalPaths.java
b/solr/test-framework/src/java/org/apache/solr/util/ExternalPaths.java
index 9d5f82a2408..940ec58b9e9 100644
--- a/solr/test-framework/src/java/org/apache/solr/util/ExternalPaths.java
+++ b/solr/test-framework/src/java/org/apache/solr/util/ExternalPaths.java
@@ -19,6 +19,7 @@ package org.apache.solr.util;
import java.net.URL;
import java.nio.file.Files;
import java.nio.file.Path;
+import org.apache.solr.common.SolrException;
/**
* Some tests need to reach outside the classpath to get certain resources
(e.g. the example
@@ -82,13 +83,14 @@ public class ExternalPaths {
}
Path base = file.toAbsolutePath();
- while (!Files.exists(base.resolve("solr/CHANGES.txt")) && null != base) {
+ while (!Files.exists(base.resolve("solr/test-framework/build.gradle"))
&& null != base) {
base = base.getParent();
}
return (null == base) ? null : base.resolve("solr/").toAbsolutePath();
} catch (Exception e) {
// all bets are off
- return null;
+ throw new SolrException(
+ SolrException.ErrorCode.SERVER_ERROR, "Failed to determine source
home", e);
}
}
}
{noformat}
(that issue required that the method be changed to no longer assume
{{CHANGES.txt}} would exist -- but was _also_ changed to throw an exception
instead of returning {{null}} per it's javadoc contracted)
> ExternalPaths clinit errors when using test-framework in downstream projects
>
>
> Key: SOLR-18092
> URL: https://issues.apache.org/jira/browse/SOLR-18092
> Project: Solr
> Issue Type: Bug
>Affects Versions: 10.0
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Solr 10 (or maybe 9.10?) broke the ability to use Solr's {{test-framework}}
> in downstream projects to develop plugins, due to changes in the way
> {{ExternalPaths.SOURCE_HOME}} is initialized.
> The docs for this variable say the variable will be {{null}} in situations
> such as "the current context is a client code base using the test framework"
> – but the {{determineSourceHome()}} method used to initialize this variable
> was changed to throw an exception instead of returning null.
>
> Because this method is called on class loading, and because {{ExternalPaths}}
> is used pervasively in the {{test-framework}} code, there is no "code change"
> downstream projects can make to resolve these exceptions.
> Instead the one workaround I have identified for this back-compat break is
> for downstream packages to add some empty dummy directories and files to
> their test classpaths...
> {noformat}
> ./src/test/resources/solr/conf/
> ./src/test/resources/solr/test-framework/build.gradle
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
