I have commited the changes due to commons-logging. Few points about it:
1. lib path changed. Now the structure is:
We will store the standard log4j properties file in common/classes directory. We will not bundle in ftpserver jar file so that it will be easier to configure the logging.
2. All the scripts wil be in bin directory. We should not have two sets of scripts (one for development and one .for binary distribution).
3. Maven files and scripts have been modified due to directory structure change.
4. LogFactory.getLog(Class) will not be called in any classes. I somehow do not like to get the Log instance using the static method in all the classes. IMHO it reduces maintainability. Instead LogFactory will be created in FtpConfigImpl (LogFactory.getFactory()) and this LogFactory will be passed using setLogFactory() method. Whenever necessary different classes will use logFactory.getInstance(Class) to get the Log object. As we are not using LogFactory.getLog() static methods in all the classes, we will have the centralized control over LogFactory.
5. Log4J is optional. Even if we have this dependency in maven, it is not necessary. If we remove log4j jar, other logging mechanism will be used - JDK logging or console logging. So LoggerPanel should not depend on log4j. If user wants to use a non-log4j log factory, LoggerPanel will not work. So to achive this, I have added one FtpLogFactory class. It just wraps the LogFactory we got by calling LogFactory.getFactory() static method in FtpConfigImpl. All the classes will get this FtpLogFactory instance. Whenever we call logFactory.getInstance(Class), FtpLogFactory will return a proxy log which will have default Log implementation and our custom Log implementation as well. Now LoggerPanel implements Log interface. The LoggerPanel sets this into FtpLogFactory.