Right, and in that regard see the reply I just sent :-) Mails crossed in transit.
On Wed, Apr 22, 2015 at 9:45 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: > My inquiry is not about removing the tgz's, simply slimming it down. Let me > review the bigtop spec to see which bits it's using. My guess is we can > drop all the dependency jars from lib and only ship our normal and uber > assemblies. > > On Wed, Apr 22, 2015 at 9:39 AM, Andrew Purtell <apurt...@apache.org> > wrote: > > > Not building a tgz will mess up Bigtop packaging, please don't rip it out > > if it's not critical. > > > > > > On Sat, Apr 18, 2015 at 2:20 PM, Nick Dimiduk <ndimi...@gmail.com> > wrote: > > > > > Nothing filed; just asking for my own enlightenment. Let me see about > > > putting our tgz's on a diet. > > > > > > Somewhat related: has anyone run make_rc.sh from a mac? It uses command > > > syntax that apparently is not compatible with BSD tools. Should I point > > it > > > at GNU tools, has anyone tried that? > > > > > > -n > > > > > > On Sat, Apr 18, 2015 at 12:36 PM, Jesse Yates <jesse.k.ya...@gmail.com > > > > > wrote: > > > > > > > Sounds like we can rip it out then - did you already file a jira? > > > > > > > > On Fri, Apr 17, 2015, 3:06 PM Nick Dimiduk <ndimi...@gmail.com> > wrote: > > > > > > > > > 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 > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
