[
https://issues.apache.org/jira/browse/LUCENE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463277#comment-17463277
]
Uwe Schindler edited comment on LUCENE-10301 at 12/21/21, 2:25 PM:
-------------------------------------------------------------------
Hi,
I made my comments on the PR, we should merge it.
I will do a followup PR to fix the TestSecrets class so also in classpath mode
it can't be used from code outside TestFramework and especially the setters
should only be called by exact classes on startup. In OpenJDK this was done the
same way in Java 8 before strong encapsulation was there. As Lucene can still
be used in classpath mode we should throw exception if anybody calls our
setters from outside the only allowed methods (easy class equality check) and
the getters are called not from test-framework only (easy prefix check on class
name). There's StackWalker::getCallerClass() to do those checks (see PR
comments).
What is a bit problematic but can be done by some from/to replacement list
automatically generated: At some point Solr needs to adapt the changes, too.
This may be very hard due to separate code base. Maybe we should provide a list
for automated search/replace of import statements, like "{{s/import
org.apache.lucene.SomeClass;/import org.apache.lucene.tests.SomeClass;/}}" so
it can be applied with a loop of "sed -i *" calls on Solr.
was (Author: thetaphi):
Hi,
I made my comments on the PR, we should merge it.
I will do a followup PR to fix the TestSecrets class so also in classpath mode
it can't be used from code outside TestFramework and especially the setters
should only be called by exact classes on startup. In OpenJDK this was done the
same way in Java 8 before strong encapsulation was there. As Lucene can still
be used in classpath mode we should throw exception if anybody calls our
setters from outside the only allowed methods (easy class equality check) and
the getters are called not from test-framework only (easy prefix check on class
name). There's StackWalker::getCallerClass() to do those checks (see PR
comments).
What is a bit problematic but can be done by some from/to replacement list
automatically generated: At some point Solr needs to adapt the changes, too.
This may be very hard due to separate code base. Maybe we should provide a list
for automated search/replace of import statements, like "{{s/import
org.apache.lucene.SomeClass;/import org.apache.lucene.tests.SomeClass;/}}" so
it can be applied with a loop od "sed" calls on Solr.
> The test-framework as a module (or a separate test-framework-module)
> --------------------------------------------------------------------
>
> Key: LUCENE-10301
> URL: https://issues.apache.org/jira/browse/LUCENE-10301
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Dawid Weiss
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The test framework has split packages. It's a follow-up to introducing
> modules but eventually the modular test subprojects will need something like
> the test framework too.
> I'm not sure whether we should start a new subproject for this or try to
> refactor the test framework, but it's a follow-up once the modules themselves
> are working and testable, I think.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
