accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: documentation on dealing with legacy Hadoop versions
Date Fri, 03 Jan 2014 16:17:42 GMT
On Fri, Jan 3, 2014 at 10:15 AM, Josh Elser <josh.elser@gmail.com> wrote:

>
>
>  2) Should we document commons-configuration similar to commons-io?
>>
>> The README already has a section about how some older versions of Hadoop
>> don't have commons-io. I think the versions given need to be tightened up
>> given (1) above (since right now it implicitly refers to versions people
>> should not be using).
>>
>> The only Hadoop distro I know of that both has proper append support and
>> does not have commons-configuration is CDH3. In addition to being a
>> vendor-specific version, it is no longer supported by said vendor.
>>
>> So would it be preferable to
>>
>>    2a) add a note after the commons-io section that gives similar
>> instructions for adding commons-configuration?
>>
>>    2b) file a jira that points out that users on CDH3 won't have commons
>> configuration, document the work around on said ticket, close it as
>> won'tfix
>>
>> The idea with the latter approach is that it would give searchers a chance
>> to find the information and give us somewhere to point people, while not
>> adding to our long-term documentation baggage. The downside is that this
>> won't be as accessible to users, so it will be more painful for them (esp
>> if they don't have regular internet access).
>>
>
> I'm not sure of what's best to do here. 1.6 undid the provided scope on
> those dependencies because 1.5 was such a pain to deal with in this regard
> (at least that's how I remember it). Perhaps a Jira is a good reference
> point and we can link to the ticket which made that change in 1.6. I doubt
> most users will find that on their own, but perhaps some might and it at
> least would keep us from having to repeat the same answer.
>
>
>>

I thought we undid the provided scope but still did not include them in our
packaging?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message