sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boglarka Egyed <b...@cloudera.com>
Subject Re: Removing com.cloudera.sqoop packages
Date Mon, 08 Jan 2018 16:59:29 GMT
Hi Szabolcs,

I really welcome this initiative, it would be a huge clean up on this
project!

I already took a look at your pull request and it indeed looks pretty
straightforward.

I will perform a deeper review and publish it on the Review Board otherwise
+1 from my side for the idea in general, 1.5 release would be a good target
for this.

Thanks for taking this effort!

Cheers.
Bogi

On Mon, Jan 8, 2018 at 2:01 PM, Szabolcs Vasas <vasas@apache.org> wrote:

> Hi All,
>
> As you probably know we still have dozens of classes in com.cloudera.sqoop
> packages which most of the cases just extend their corresponding class in
> org.apache.sqoop package without adding extra functionality.
> These classes make the code harder to read and navigate, they are already
> deprecated but because of backward compatibility considerations we were not
> able to remove them.
> The community was planning on a release containing breaking changes (we
> called it 1.5) I think it would be a great candidate to include this
> cleanup.
> I have created a ticket <https://issues.apache.org/jira/browse/SQOOP-3273>
> for doing this task and submitted a patch as well. I think the easiest way
> to take a look at it is to review the commits in my Sqoop fork:
> https://github.com/szvasas/sqoop/tree/cloudera_package_removal
> Note that this is change which basically affects all of the files in the
> Sqoop project, but in the majority of the cases replacing the
> com.cloudera.sqoop class to its corresponding org.apache.sqoop class was
> just a find and replace command so I consider this a relatively low risk
> change.
> Please feel free to reply to this email with your questions and concerns
> and if you have some time please take a look at the changes.
>
> Thanks and regards,
> Szabolcs
>

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