On Feb 28, 2012, at 11:29 AM, Arvind Prabhakar wrote:
> On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera <l...@toolazydogs.com>
> wrote:
>>
>> On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
>>
>>> On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera <l...@toolazydogs.com>
>>> wrote:
>>>>
>>>> On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
>>>>
>>>>> On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera <l...@toolazydogs.com>
>>>>> wrote:
>>>>>> On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
>>>>>>> On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting
>>>>>>> <jukka.zitt...@gmail.com> wrote:
>>>>>>>> On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu <akaras...@apache.org>
>>>>>>>> wrote:
>>>>>> I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
>>>>>
>>>>> How about phrasing it as "old Sqoop code" instead. :-)
>>>>>
>>>>> Really it's about respect for existing users and others migrating to
>>>>> Apache. It's also about respect for the people doing the work. That's
>>>>> my understanding from discussions with the team at least.
>>>>>
>>>>>> I don't see the technical requirement that this code needs to stay at
>>>>>> Apache and not Cloudera.
>>>>>
>>>>> I agree that this potentially could be an issue, but whether it's a
>>>>> technical requirement is up to the team who's doing the work. If
>>>>> Apache feels that there is a requirement that no project releases
>>>>> code/document/etc... under any package other than org.apache.* then
>>>>> that should be clearly defined and communicated. At this point my
>>>>> understanding is there is no such requirement.
>>>>
>>>>
>>>> public class MySQLManager
>>>> extends org.apache.sqoop.manager.MySQLManager {
>>>>
>>>> public MySQLManager(final SqoopOptions opts) {
>>>> super(opts);
>>>> }
>>>>
>>>> }
>>>>
>>>> If all the code is like this it is absolutely ridiculous to have this at
>>>> Apache and not Cloudera.
>>>
>>> Please see [1] for details on why the code is like this. The short
>>> summary is that binary compatibility requires us to respect all
>>> extension points within the code.
>>>
>>> [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
>>
>> IIUC, this document merely outlines how the move should be performed. This
>> has been completed and what's left are bindings for those who wish to use
>> the old bindings from the old project. There's no technical reason why
>> those bindings for the old project must be housed here at Apache.
>
> You are right that it outlines how the move should be performed. Along
> with that it also describes the motivation and specific technical
> requirements to be fulfilled. Following are the relevant quotes from
> the document:
>
> [From Overview - Motivation]
> Considering that there is a lot of third party code that is developed
> on top of/to work with Sqoop, this migration is particularly risky for
> backward compatibility and thus requires careful handling. This
> document outlines the steps that seem reasonable for such migration.
>
> [From Migration-General Approach - Technical Requirement]
> When migrating a class from its previous namespace to the new, the key
> requirement to address is that any code written to the old class
> should still work at binary compatibility level. This also implies
> that such code should be able to recompile with the migrated code base
> without any modifications. In order to enable this, the general
> approach is as follows:
>
> * Any old public/protected/default access level API should be
> preserved as is, but marked deprecated.
> * Any logic that exists in this API should be migrated to the new namespace.
>
> Note that API is not just method signatures but includes all aspects
> of implementation such as class hierarchies, type compatibility,
> static and non-static state etc.
I think that it's good to have binary compatibility with Cloudera's old
bindings. I still don't see why it's a requirement for Apache to house code
whose sole use is to provide backward compatible bindings for Cloudera's old
bindings.
Regards,
Alan
