Another option for the sake of discussion, is to have a hadoop 3
version. For example
<dependency>
<groupId>org.apache.accumulo</groupId>
<artifactId>accumulo-core</artifactId>
<version>1.8.2-hadoop3</version>
</dependency>
I think this horrible in too many ways to enumerate, not advocating
for it. Just trying to exhaustively think through the solution space.
On Tue, Dec 5, 2017 at 3:58 PM, Josh Elser <els...@apache.org> wrote:
> Another potential suggestion I forgot about: we try to just move to the
> Hadoop shaded artifacts. This would invalidate the need to do more, but I
> have no idea how "battle-tested" those artifacts are.
>
>
> On 12/5/17 3:52 PM, Keith Turner wrote:
>>
>> If we do the following.
>>
>> * Drop ZooKeeperInstance.ZooKeeperInstance(Configuration config) method.
>> * Drop extends from ClientConfig
>> * Add a method ZooKeeperInstance.ZooKeeperInstance(ClientConfig config)
>>
>> Then this will not be binary compatible, so it will still be painful
>> in many cases. It may be source compatible.
>>
>> For example the following will be source (but not binary) compatible.
>>
>> ClientConfiguration cc = new ClientConfiguration(file);
>> //when compiled against older version of Accumulo will bind to
>> method with commons config signature
>> //when recompiled will bind to clientconfig version of method
>> ZooKeeperInstance zki = new ZooKeeperInstance(cc);
>>
>> The following would not be source or binary compatible.
>>
>> Configuration cc = new ClientConfiguration(file);
>> ZooKeeperInstance zki = new ZooKeeperInstance(cc);
>>
>>
>> On Tue, Dec 5, 2017 at 3:40 PM, Josh Elser <els...@apache.org> wrote:
>>>
>>>
>>>
>>> On 12/5/17 3:28 PM, Keith Turner wrote:
>>>>
>>>>
>>>> On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser<els...@apache.org> 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).
