[
https://issues.apache.org/jira/browse/SOLR-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369719#comment-17369719
]
Istvan Farkas commented on SOLR-14660:
--------------------------------------
I'm currently working on separating the tests.
(1) There are test classes in Solr core which are referred to by hdfs test
classes, for example org.apache.solr.util.MockCoreContainer.
Gradle does not allow defining dependencies between test artifacts of different
modules. It defines the concept of testFixtures for this purpose - it has a
built-in plugin that handles the src/testFixtures directory, builds a fixtures
jar file from all of those classes, and the fixtures have automatic
dependencies to the source classes of their defining module. Another module
(like the HDFS contrib) can define dependencies to the solr core test fixtures
like this: testImplementation(testFixtures(project(“:solr:core”)))
Another solution could be to move these shared classes to the test framework
project’s src. The MockCoreContainer seems to be a bit solr core-specific so
for calles like this which need to be shared, the testFixture solution looks a
better fit to me, but I’d like to discuss if it’s okay to use them or if there
is a better way.
(2) The Hadoop and HDFS code in Solr are a bit intertwined. One example is the
org.apache.solr.cloud.hdfs.HdfsTestUtil. This class is
referred to both by HDFS test classes and Hadoop test classes. We don’t want a
Core->HDFS module (circular) reference. The Hadoop test classes invoke the
checkAssumptions method of this class, and the other methods are there to set
up a hdfs mock cluster. Since at this step we would like to separate HDFS only,
I plan to refactor this and similar classes for example by splitting to
HdfsTestUtil and HadoopTestUtil, and try to separate the Hadoop and HDFS code
so there is no circular dependency.
Not sure if this will be an easy one since the Hadoop classes might load Hdfs
classes as well - I will need to experiment with these and find a clean
solution.
(3) There are some classes where a Hdfs test class extends a Solr Core Test
class, for example:
HdfsChaosMonkeyNothingIsSafeTest extends ChaosMonkeyNothingIsSafeTest
MoveReplicaHDFSTest extends MoveReplicaTest
HdfsUnloadDistributedZkTest extends UnloadDistributedZkTest
Since the references between test projects are not possible, this will need
some changes in order to work. Moving the parent class (eg.
ChaosMonkeyNothingIsSafeTest) to a test fixture or to the test framework would
not work here since the parent classes are tests themselves so they need to be
in the core tests to be executed as tests (Additionally, the test fixtures get
automatic dependencies to the src classes, but not to the dependencies of that
src project itself, so I would have to add multiple dependencies to the core
test fixtures, like junit, lucene core, etc.).
I will need to refactor the classes like these. For example, the
HdfsChaosMonkeyNothingIsSafeTest is a subclass of a test framework class
(AbstractFullDistribZkTestBase), I will check if it's better to make
HdfsChaosMonkeyNothingIsSafeTest a subclass of AbstractFullDistribZkTestBase as
well, or if the HdfsChaosMonkeyNothingIsSafeTest->ChaosMonkeyNothingIsSafeTest
inheritance is really needed, I'll need to introduce a common base class of the
2, which can be put to either the test framework or the test fixtures of Solr
Core so it can be shared between the core tests and the HDFS tests.
> Migrating HDFS into a package
> -----------------------------
>
> Key: SOLR-14660
> URL: https://issues.apache.org/jira/browse/SOLR-14660
> Project: Solr
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Priority: Major
> Labels: package, packagemanager
>
> Following up on the deprecation of HDFS (SOLR-14021), we need to work on
> isolating it away from Solr core and making a package for this. This issue is
> to track the efforts for that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
