joshelser commented on issue #687: Hbase compat buildtime URL: https://github.com/apache/phoenix/pull/687#issuecomment-580447053 It looks like omid is bringing in a custom version of hbase-endpoint to the assembly (looking at the bin tarball's lib directory): ``` [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ phoenix-assembly --- [INFO] org.apache.phoenix:phoenix-assembly:pom:5.1.0-SNAPSHOT [INFO] +- org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT:compile [INFO] | +- org.apache.omid:omid-hbase-shims-hbase2.x:jar:1.0.1:compile [INFO] | | +- org.apache.hbase:hbase-endpoint:jar:2.0.1:compile ``` In the above, I had overwritten the version of the hbase dependency to be 2.1.7, but hbase-endpoint was still at 2.0.1. We can get rid of that my just setting the dependency on hbase-endpoint in phoenix-core, I think. At least, I think that would be the cleanest way to work around it. I think I've convinced myself that renaming the compat modules from 2.y.z to 2.y is a good idea. If there is some .z release which doesn't work for Phoenix, let's just preclude that value from being set by creating a maven-enforcer-plugin in that compat module's profile to fail on that value. The builtin rule RequireProperty lets us do exactly that (sadly, not via the nice version range syntax) with a regex like `2\.2\.[1-9]`. Recognizing that this will fail if we get to `2.2.10`, we can also write a custom enforcer rule which would do exactly what we want. I just think that's overkill for now :) > supporting HBase version ranges, which may not even be continuous (e.g. the 2.0.1 module supports both 2.0 and 2.1 releases made in the same timeframe, but breaks on a change introduced in both branches). I was thinking more about this. We don't need separate compat modules for (most of) 2.1.x and 2.2, but would it reduce user-error to make a profile that just activates `phoenix-compat-hbase-2.2` when the user sets `-Dhbase.compat.version=2.1`? In HBase, when dealing with Hadoop dependencies, we have a property named `hadoop.profile` which is doing the same thing you're doing for HBase now. It would be nice for consistency to rename `hbase.compat.version` to be `hbase.profile`. I'll go through the rest of the code-changes, but I think, with the above, I am happy with the build-system level changes :) Awesome work.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
