Hi David, [ not a review ]
> On 20 Dec 2021, at 14:54, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > Hello everyone, > > I've completed the task of getting the test framework to not share any > packages with Lucene core - this is here: > > https://issues.apache.org/jira/browse/LUCENE-10301 > <https://issues.apache.org/jira/browse/LUCENE-10301> > https://github.com/apache/lucene/pull/551 > <https://github.com/apache/lucene/pull/551> > > Basically everything remains the same, except for the changed package prefix. > The patch is rather large because it cuts across all of the code (imports, > mostly). There are also some minor tweaks to expose package-private internals > in the core to the test framework, now residing in a different package. I think that the approach is reasonable (to inject ’test’ into the package name between the reverse DNS prefix and the specific logical technology suffix). I’ve played a little with similar in the Elasticsearch codebase - but not yet advanced it to a point that eliminates all split packages. TestSecrets also seems reasonable. It’s a pity that it intrudes somewhat on the actual product code, but not to any extent that would be concerning. It’s great that you can now have a test_framework module. And, from what I can see, the moduleXXX configurations that you introduced recently work just fine for the Gradle dependency configuration. ( I wish that we were at a similar point in ES, but recent distractions have slowed progress :-( ) Once this is in, then it will be possible to patch area specific unit tests into the actual product module and `require` the framework, right? And if we had that, it’s not a big leap to maybe refactor some of the secrets to be injected too ( but I accept that that is not really necessary either, and I’m not sure how the IDEs or Gradle would like this ) -Chris.
