You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Why not just put them under hbase-client test code?
Because one test jar should not import another ; test jars should be leaf nodes in any dependency graph. I want to consume these classes from hbase-server:test:jar.
Why not just put them under hbase-client test code?
Because one test jar should not import another ; test jars should be leaf nodes in any dependency graph. I want to consume these classes from hbase-server:test:jar.
Is this a best practice? At least in the current hbase code base, we need to depend on the test jar of some modules, for example HBaseTestingUtil is in hbase-server module, and we use it in hbase-mapreduce module.
You can check the pom definition, we have lots of tests jar dependencies…
Is this a best practice? At least in the current hbase code base, we need to depend on the test jar of some modules, for example HBaseTestingUtil is in hbase-server module, and we use it in hbase-mapreduce module.
You can check the pom definition, we have lots of tests jar dependencies…
The HBaseTestingUtility is an especially bad example, because it's how we suggest users test their HBase applications (I do see that on branch-2 it's marked as @deprecated, with no mention of a replacement). In that sense, it's a part of our public API that is provided by a test jar!
I think dependency on a test jar is bad practice and maven authors appear to agree -- you have to go out of your way to have maven produce test jars, they're disabled by default. However, I don't want to hold up the otel improvements on these kinds of layout/organization improvements to our repo.
I have stumbled into one annoyance -- when a dependency jar is of type:test-jar, it seems that the transitive dependencies are not included. So for example, say I want to use the OpenTelemetryClassRule and OpenTelemetryTestRule defined in hbase-server:test from hbase-endpoint:test. These rules use classes from io.opentelemetry:opentelemetry-sdk-testing. This transitive dependency is not included automatically -- hbase-endpoint:test must explicitly include both hbase-server:test and io.opentelemetry:opentelemetry-sdk-testing, otherwise a NoClassDefFoundError is thrown at test time.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Move
SpanDatamatcher support classes to new module. Probably there are others, but start with these for now.This is a prerequisite for further progress with the otel effort.