[
https://issues.apache.org/jira/browse/HBASE-21071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16586689#comment-16586689
]
Mingliang Liu edited comment on HBASE-21071 at 8/21/18 12:23 AM:
-----------------------------------------------------------------
[~Apache9] Thanks for the input. I understand the concern of
{{@InterfaceAudience.Public}}, though I don't like its being Public either. I
was thinking in master branch it's OK to remove those overload methods as it's
for a new major release. While in branch-2 we deprecate those methods instead
of phasing out. However, I have no idea about HBase's commitment to IA.Public
class across major releases.
For starting a brand new and better test utility tool, I like the idea. Ideally
as [~stack] suggested, we can use the option class in this patch and write a
builder {{MiniHaseClusterBuilder}} to create {{MiniHaseCluster}} object on
which we can call start/stop. That work is bigger than the scope here. I can
help with that later.
This patch is most orthogonal to that effort and can add value to existing HTU.
If we strictly respect the Public annotation, I think perhaps we can deprecate
those methods instead of removing in both {{master}} and {{branch-2}}.
Downstream applications using old overload methods will still compile but they
will get checkstyle and compile warnings. If this makes sense, I can bring back
the deleted 10+ method with deprecation annotation and implement them using
option builder.
[EDIT] Patch v3 is for checkstyle warnings not yet bring the deleted methods
back.
was (Author: liuml07):
[~Apache9] Thanks for the input. I understand the concern of
{{@InterfaceAudience.Public}}, though I don't like its being Public either. I
was thinking in master branch it's OK to remove those overload methods as it's
for a new major release. While in branch-2 we deprecate those methods instead
of phasing out. However, I have no idea about HBase's commitment to IA.Public
class across major releases.
For starting a brand new and better test utility tool, I like the idea. Ideally
as [~stack] suggested, we can use the option class in this patch and write a
builder {{MiniHaseClusterBuilder}} to create {{MiniHaseCluster}} object on
which we can call start/stop. That work is bigger than the scope here. I can
help with that later.
This patch is most orthogonal to that effort and can add value to existing HTU.
If we strictly respect the Public annotation, I think perhaps we can deprecate
those methods instead of removing in both {{master}} and {{branch-2}}.
Downstream applications using old overload methods will still compile but they
will get checkstyle and compile warnings. If this makes sense, I can bring back
the deleted 10+ method with deprecation annotation and implement them using
option builder.
> HBaseTestingUtility::startMiniCluster() to use builder pattern
> --------------------------------------------------------------
>
> Key: HBASE-21071
> URL: https://issues.apache.org/jira/browse/HBASE-21071
> Project: HBase
> Issue Type: Bug
> Components: test
> Affects Versions: 3.0.0
> Reporter: Mingliang Liu
> Assignee: Mingliang Liu
> Priority: Major
> Attachments: HBASE-21071.000.patch, HBASE-21071.001.patch,
> HBASE-21071.002.patch, HBASE-21071.003.patch
>
>
> Currently there are 13 {{startMiniCluster()}} methods to set up a mini
> cluster. I'm not surprised if we have a few more in future. It's good to
> support different combination of optional parameters. We have to pick up one
> of them carefully while still wondering the default values of other
> parameters; if we add a new option, we may bring more new methods.
> One solution is to use builder pattern: create a class {{MiniClusterOptions}}
> along with a static class {{MiniClusterOptionsBuilder}}, create a new method
> {{startMiniCluster(MiniClusterOptions)}}. In {{master}} we delete the old 13
> methods while in branch-2, we deprecate the old 13 methods.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
