[ http://issues.apache.org/jira/browse/DIREVE-316?page=comments#action_12360829 ]
Emmanuel Lecharny commented on DIREVE-316: ------------------------------------------ As said Alex, forking from commons lead to less dependencies to those jars. And this is good. Of course, I don't know if it's really interesting to fork commons-collections... Trustin as also forked its own version of NIO byteBuffer. The problem is that ldap-common depend on asn1-codec, which contains a StringUtils class (my bad). I suggest that we create a directory-common subproject, which will contains all those common classes, in a package named (as Trustin suggested) org.apache.directory.common. The classes should *not* overlap with o.a.commons classes (I think that StringUtils must be merged with StringTools). The problem with this overlapped names is that you may think that the class is a standard one (I have lost some time before understanding that ByteBuffer was overlapped :( ) So, as a best effort, I think that the minimum should be done right now, and the next move (after 1.0) could be a major refactoring, with a drastic reduction of the number of external jars included. 1.1 could be a "clean and sweep" effort, with a focus put on performance and memory consumption. (and code review, too ;) wdyt? > StringUtils & StringTools > ------------------------- > > Key: DIREVE-316 > URL: http://issues.apache.org/jira/browse/DIREVE-316 > Project: Directory Server > Type: Improvement > Reporter: Emmanuel Lecharny > Priority: Minor > > We have two classes which semantics are almost the same : > - StringTools in ldap-common > - StringUtils in asn1-codec > The second one is horrible, because it overlaps with the > a.o.commons.lang.StringUtils. > I think it could be good to merge both classes into StringTools, and to move > this class in a common subproject to be created (ads-commons, for instance). > wdyt ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
