PHOENIX-5827 Add a maven repo to PQS

[joshelser]

• Move the cluster.xml to the prescribed location per Maven convention.
• Use maven-assembly-plugin to create a Maven repo in the assembly
• Pull the phoenix-client jar from central and localize so PQS can actually function
• Fix the phoenix-client jar name so that it's picked up by phoenix_utils.py
• Prevent old Jetty versions from sneaking in on HBase 1.x
• Build the ServerCustomizer and expose configuration to enable it

[stoty]

Given that the PQS server artifact is supposed to be phoenix and HBase version agnostic I think that we should not add the thick client repo to the assembly by default.

We could perhaps hide that in a profile that can be activated by something like
'-Dadd.thick.client.to.assembly -Dphoenix.version= -Dphoenix.classifer'

I also think that exposing something like mvn magic:goal -Drepo.target.dir= -Dphoenix.version= -Dphoenix-classifer that could be used to build/rebuild the the client repo would also be useful.

[joshelser]

Given that the PQS server artifact is supposed to be phoenix and HBase version agnostic I think that we should not add the thick client repo to the assembly by default.

So, this is how I would call PQS broken right now. The assembly it creates is useless. PQS requires a phoenix-client jar, we don't provide one, and we don't give any indication that you have to include one.

We have a dependency on a version of Phoenix yes, but the ability to set -Dphoenix.version (and -D phoenix.hbase.classifier=.. if you're going against your HBase profile work in 5.x) which lets a user build a "proper" assembly for their own use-cases.

[joshelser]

I also think that exposing something like mvn magic:goal -Drepo.target.dir= -Dphoenix.version= -Dphoenix-classifer that could be used to build/rebuild the the client repo would also be useful.

I can see where you are coming from with this approach. I worry that, with a large monolithic build process, deferring this to a later step would increase the complexity of building PQS. Being able to build the entire PQS assembly in one command is best, IMO.

We could hide this behind a profile on the build (but my old point of building a useless PQS assembly still applies) to skip this repo creation.

[stoty]

The queryserver assembly is a mess in every way.
I have PHOENIX-5829 (opened today) and PHOENIX-5771 open for these issues.

The problem is that we should provide something on the download page, and it's not feasible to add every combination there, so I think that we should generate a bare-bones assembly (plus instructions on how to add phoenix-client, and possible regenerate the client maven repo) if we want to have binary PQS tarball distro at all.

So it could be something like this:

• Generate a bare-bones assembly be default
• A profile that generates a full-fat assembly, with phoenix-client included in the PQS classpath, as well as the client repo
• Preferably a way to invoke the assembly generation process separately, to handle phoenix version updates. This could simply copy whatever file is specified, or use the maven client coordinates

[joshelser]

Generate a bare-bones assembly be default. A profile that generates a full-fat assembly, with phoenix-client included in the PQS classpath, as well as the client repo

Let me work on this. I think I like this idea best.

Preferably a way to invoke the assembly generation process separately, to handle phoenix version updates. This could simply copy whatever file is specified, or use the maven client coordinates

Right now, I'm not sure how to "merge" a repo we make for PQS client with another one later. Automating an "overlay" seems a reasonable thing we could script up later.

[joshelser]

ab18594 pushes the phoenix-client bundling into a profile, and adds some documentation.

However, the problem with this all is that allowing jetty-util 6.1.26 (from Hadoop 2 and HBase 1) breaks our need for Jetty 9 (that Avatica pulls in). Need to figure this out.

[joshelser]

ad51a2b REALLY opened up the rabbit hole. Hadoop2/HBase1 have a big issue with Jetty6 leaking out of the classpath. We aren't going to fix that problem, so we either have to bandaid it or not support it in PQS.

Since not supporting Phoenix 4 isn't an issue yet, we gotta work around it. I moved all ITs to their own module where Jetty6 can run wild, and anything which is touching our Jetty 9.4 classes into queryserver (so they can be shaded). AFAICT, this works, but is a pain in the butt.

A mvn verify runs locally for me, but I still need to retest:

• mvn verify -Dphoenix.version=5.1.0-SNAPSHOT still works
• The assembly (and the new flag) still create reasonable tarballs

[joshelser]

88250e5 is the last one (maybe unwinding some changes I made in passing that are unrelated). This validates that the packaging and the -Ppackage-phoenix-client profiles works as you would expect.

All tests run against Phoenix 4.x. IT's do not run against 5.x, but that should be a separate issue at this point (I think we'll have to introduce some profile work to support testing against both).

[stoty]

This generally looks great, apart from breaking the ITs in the other modules.

[joshelser]

dfc969e should address all of the great feedback from Istvan (thanks!)

Let me re-test locally. Glancing at the tarball, everything still looks to be in order.

[joshelser]

Alright, this works for me locally.

I have noticed that LoadBalancerEnd2EndIT fails if you have ZooKeeper running locally. Will spin out another fix for that.

[stoty]

+1 LGTM