| Emmanuel Lecharny (JIRA) 2005-12-19, 5:45 pm |
| [ http://issues.apache.org/jira/brows...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 StringUtil
s 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 pu
t 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/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|