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 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 al
What we do is set up version independent symlinks for reference from
elsewhere for installing the server jar or finding the client jar for JDBC (
https://github.com/apache/bigtop/blob/master/bigtop-packages/src/common/phoenix/install_phoenix.sh)
. We also replace dependency jars in the Phoenix lib/
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 wrote:
> Not bui
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 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_r
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, Ap
Sounds like we can rip it out then - did you already file a jira?
On Fri, Apr 17, 2015, 3:06 PM Nick Dimiduk 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
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 1
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
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 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 ja
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 inadeq
10 matches
Mail list logo
