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