My understanding is that we already run via standalone uberjar for sqlline.py and psql.py ... which may be a bug for folks who have deployed on versions of HBase/Hadoop we're not packaging against. The only things in their class path is the HBASE_CONF_DIR and the client assembly jar.
On Fri, Apr 17, 2015 at 2:14 PM, Jesse Yates <jya...@apache.org> wrote: > I think it was for convenience of packaging. While we have transitive > dependencies, they resolve when including the HBase/Hadoop classpaths as > well. I think mostly this was to make it easy to run from the tarball using > sqline or the various python scripts in the bin/ directory. > > If no one is using them, then by all means, we should remove building them. > Or build them completely so we can run standalone (and then maybe people > will use it). > > On Fri, Apr 17, 2015 at 2:06 PM Mujtaba Chohan <mujt...@apache.org> wrote: > > > Jesse I think you initially worked on Phoenix assembly tar and jar > > packaging. Any thoughts? > > > > On Fri, Apr 17, 2015 at 12:39 PM, Nick Dimiduk <ndimi...@gmail.com> > wrote: > > > >> Quick question: > >> > >> Why do we package up our dependencies in the TGZ? There's no Phoenix > >> executable, just a fat jar for the RS and a fat client jar for > >> applications. Why bother with lib and all this business? > >> > >> If we are trying to package up all our dependencies in the tgz, our > >> current > >> means are inadequate. A little shell gymnastics*** with mvn > >> dependency:list > >> shows me 201 total transitive dependencies for Phoenix, of which we only > >> package 38. > >> > >> So why bother? > >> > >> Thanks, > >> Nick > >> > >> *** > >> $ mvn dependency:list | egrep '\[INFO\] \w+' | grep compile | cut -d: > >> -f1-3 | sort | uniq | wc -l > >> 201 > >> > > > > >
