accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Tue, 05 Dec 2017 21:15:10 GMT
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 <elserj@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 <elserj@apache.org> wrote:
>>>
>>>
>>>
>>> On 12/5/17 3:28 PM, Keith Turner wrote:
>>>>
>>>>
>>>> On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser<elserj@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).

Mime
View raw message