Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 15EA7200D5D for ; Tue, 5 Dec 2017 21:40:55 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 1472E160BF1; Tue, 5 Dec 2017 20:40:55 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5AFAA160C1B for ; Tue, 5 Dec 2017 21:40:54 +0100 (CET) Received: (qmail 74779 invoked by uid 500); 5 Dec 2017 20:40:53 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 74766 invoked by uid 99); 5 Dec 2017 20:40:53 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Dec 2017 20:40:53 +0000 Received: from hw10447.local (outbound.hortonworks.com [192.175.27.2]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 2B1E71A009B for ; Tue, 5 Dec 2017 20:40:53 +0000 (UTC) Subject: Re: [DISCUSS] Hadoop3 support target? To: dev@accumulo.apache.org References: <06fc51f8-814a-2899-c62b-15c7f1aeca0f@apache.org> <0174acbf-478d-eeee-32d5-6fb5255ad7d2@apache.org> <007301d36d57$7b7abce0$727036a0$@gmail.com> <3d2e197b-f3ad-4c37-69a1-b612f9a03a28@apache.org> From: Josh Elser Message-ID: Date: Tue, 5 Dec 2017 15:40:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:58.0) Gecko/20100101 Thunderbird/58.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit archived-at: Tue, 05 Dec 2017 20:40:55 -0000 On 12/5/17 3:28 PM, Keith Turner wrote: > On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser wrote: >> Interesting. What makes you want to deprecate ClientConfig entirely? >> >> I'd be worried about removing without sufficient thought of replacement >> around. It would be a bit "churn-y" to introduce yet another way that >> clients have to connect (since it was introduced in 1.6-ish?). Working >> around the ClientConfig changes was irritating for the downstream >> integrations (Hive, most notably). > Ok maybe thats a bad idea, not looking to cause pain. Here were some > of my goals. > > * Remove commons config from API completely via deprecation cycle. > * Introduce API that supports putting all props needed to connect to > Accumulo in an API. > > I suppose if we want to keep ClientConfig class in API, then there is > no way to remove commons config via a deprecation cycle?? We can't > deprecate the extension of commons config, all we can do is just drop > it at some point. > My line of thinking is that the majority of the time, we're creating a ClientConfiguration by one of: * ClientConfiguration#loadDefault() * new ClientConfiguration(String) * new ClientConfiguration(File) Granted, we also inherit/expose a few other things (notably extending CompositeConfiguration and throwing ConfigurationException). I would be comfortable with dropping those w/o deprecation. I have not seen evidence from anyone that they are widely in use by folks (although I've not explicitly asked, either).