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.
Thanks,
Arvind Prabhakar
>
>
> Regards,
> Alan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
