[
https://issues.apache.org/jira/browse/HBASE-24066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068098#comment-17068098
]
Nick Dimiduk commented on HBASE-24066:
--------------------------------------
No irking intended; off-hand, it strikes me as something that makes HBase less
stable in production, not more; something that enabled chaos instead of
discipline around production deployments. My limited imagination doesn't
conjure a case where this is helpful to the organization that deploys it. Maybe
you want to document some incantation for running a tool that starts with
{{`java -jar "$(curl ...)"`}} ? What's wrong with the {{bin/hbase}} script? Why
not put effort into exposing a fully featured http/json/protobuf interface out
of the box?
bq. No thank you, that's not the purpose of the cluster.
You're right, this was very terse, but it includes my justification: "hosting
thick-client library artifacts is not the purpose of the cluster". My reasoning
is that artifact distribution is not the purpose of the cluster or webUI. Why
would be burden production hosts with artifact distribution? Why would we
encourage deployments where the production hosts are on the same networks as
developers? There are plenty of other means of distributing artifacts available
to an organization, means that do not couple development to production, that
are managed directly by IT and IT's policies.
Do we not distribute these artifacts via our tarballs? Wouldn't they be
installed on any host via "normal" means?
The -1 expresses the strength of my opinion based on what I've seen so far
(this JIRA and the PR). I considered -0 and decided that no, I think this is
really not a good idea. Of course a quorum of committers overrides a single
vote, does it not? Please change my mind with some use-case ideas/stories.
> Expose shaded clients through WebUI as Maven repository
> -------------------------------------------------------
>
> Key: HBASE-24066
> URL: https://issues.apache.org/jira/browse/HBASE-24066
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Minor
>
> Props to [~busbey] for this idea.
> We have a number of shaded jars which are (largely) sufficient for launching
> any Java application against HBase. However, if users have multiple versions
> of HBase in their organization, it might be confusing to know "which client"
> do I need to use? Can we expose our shaded clients from HBase in such a way
> that build tools can just ask HBase for the client jars they should use?
> The idea here is that we can use embedded Jetty to "fake" out a Maven
> repository that users can put in their client applications. We have no extra
> burden from HBase because we already are packaging these jars. I'll link an
> example Maven application which uses this "feature".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
