Thanks for your suggestion. I was able to send a review request. To answer your questions:
Any reason MainframeManager inherits from the deprecated com.cloudera.sqoop.manager.ConnManager and not from org.apache.sqoop.manager.ConnManager? I noticed you also use the deprecated SqoopOptions.
I will change MainframeManager to inherit from org.apache.sqoop.manager.ConnManager. It is not a problem. However, I still have to use deprecated SqoopOptions because importing to HBase or Accumulo requires using HBaseImportJob or AccumuloImportJob respectively. The constructors for these classes can take only deprecated SqoopOptions.
MainframeFTPClientUtils depends on org.apache.commons.net. I didn't see commons-net added as a dependency to ivy.xml.
When the dependencies for Apache Hadoop jar files are picked up, commons-net is picked up automatically. If you think it is a good idea to update ivy.xml in Sqoop to make it independent of that, I will add it to ivy.xml.
To answer your questions:
Can we add documentation (stored in src/docs/user) for the new tool?
Good suggestion. I will add it in the next version of the patch.
Can move files Mainframe* from org.apache.sqoop.mapreduce.* to a special sub-package mainframe forming org.apache.sqoop.mapreduce.mainframe?
I thought about it initially. However, it was not clear whether I should do it considering the existing directory structure. There are several *ImportJob.java, *InputFormat.java, and *Mapper.java classes already in org.apache.sqoop.mapreduce. Sure, I can create org.apache.sqoop.mapreduce.mainframe if it avoids cluttering of org.apache.sqoop.mapreduce.