Hi! First of all, a heads up that I have merged the Client-Server code separation (PHOENIX-6053) patch a few minutes ago.
A huge thanks to Aron for turning my two years old POC patch into a merge-ready patch, and handling all the change requests and numerous rebases. The patch has been discussed on the ticket <https://issues.apache.org/jira/browse/PHOENIX-6053> and in the 2021 <https://lists.apache.org/thread/hs4klbc04n4gh62z17pznc0rkspjg6jx> and the recent <https://lists.apache.org/list?dev@phoenix.apache.org:2023-10:PHOENIX-6053> email threads. *A very quick recap:* *phoenix-core* has been split into two modules* phoenix-core-client* and *phoenix-core-server*. *Phoenix-core-server* depends on* phoenix-core-client*, as we more or less need the full client code on the server side. phoenix-core includes all the code needed the JDBC driver, but does not include anything that is used exclusively on the server side (coprocessors, split policies, etc) *phoenix-core* is still around, it retains all the tests (as the majority of them ), and it also acts as a compatibility dependency, which transitively depends on both client and server. *Backporting to 5.1:* We need to make a decision on whether to backport this change into 5.1 or not. Against: - It is a huge patch by file count - maven module structure changes For: - Backports to 5.1 will be a *nightmare* if we don't backport this change - The actual code changes are minimal, and the behavioural changes should be non-existent. - Dependency compatibility should be handled by the phoenix-core package - Users get the advantages without having to wait for 5.2. We have three options: - Backport to 5.1.4 - Backport post 5.1.4 - Do not backport *I really need to hear your take on this.* *Next steps:* This change in itself does little apart from cleaning up the code, but it enables a number of important new features (these were originally planned to be included in PHOENIX-6053, but I decided to split them to separate tickets to keep the scope manageable): - PHOENIX-7137 <https://issues.apache.org/jira/browse/PHOENIX-7137> Create *phoenix-client-lite* shaded JAR without server-side dependencies - This adds a new shaded client variant, *phoenix-client-lite *(names are up for discussion), which omits the server-side code and its dependencies. It is ~20 MB smaller, and pollutes the classpath less. - PHOENIX-7139 <https://issues.apache.org/jira/browse/PHOENIX-7139> Create *phoenix-mapreduce-byo-shaded-hbase* artifact for use by connectors - This allows using the hbase-shaded-client and phoenix on the same classpath. Up until now, you had to do that by using the phoenix-core dependency from Maven, or by using the HBase libraries shaded into phoenix-client. The current phoenix-client will fail hard with any other Hbase libraries on the classpath due to relocation conflicts. - Allows updating the hbase client code without rebuilding Phoenix - Solves the protobuf 2.5.0 woes, which make it impossible to use code/libraries using unshaded protobuf 3.0 together with Phoenix. This was, and remains the original driver behind PHOENIX-6053. - Allows using Hadoop extensions with Phoenix. Being able to use the various cloud connectors like AWS S3a without shading hundreds of megabytes of additional code into phoenix-client was another driver for this change. - This is the same shading setup already used by the shaded Hive and Spark connector artifacts. - Create a phoenix-client-byo-shaded-hbase which would be the same as *phoenix-mapreduce-byo-shaded-hbase*, but omit the phoenix server-side code. - I'm on the fence about this. phoenix-mapreduce-byo-shaded-hbase should be usable for this purpose. The server-side phoenix code is not that big, and *phoenix-mapreduce-byo-shaded-hbase *already omits any server-side dependencies which could cause conflicts. - Will need to run to see if this is needed / useful.
