|
[
Permlink
| « Hide
]
Ersin Er added a comment - 19/Dec/05 01:33 AM
It's a good idea to merge related utilities and other packages while doing some cleap up for the whole project. For example there is also a ClassUtils which is just a copy of an old release of jakarta commons ClassUtils. I also needed some ready baked Class utils from Spring project and included used them in sandbox. It's better we tidy up this Utils stuff to achieve better reusable components.
I tried to fork as much from commons as I could into our common area. However I did not complete this job. We probably use less than 3% of commons jars while we depend on 3-4 Mb worth of jars from commons. This is something I intend to complete when I get back. I want no dependencies on commons jars when I am done and I want to reduce our footprint.
There are also other issues like having too many projects all over but this is another issue. We need an automatic fork generator plugin now. This shouldn't be that hard. We could replace the package names simply. For example, from org.apache.commons.lang to org.apache.directory.common.fork.lang And let's put all our own utility classes and forks there. WDYT?
Hmm.. but if we're going to strip all unused classes, then it becomes so complex. We'll have to use a library such as JDepend. The question would be 'is it worth for us take that much time on this issue?' 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? The original reason we forked commons-* is because of the infamous class loader problem when ApacheDS is embedded in WAS. This became a problem because WAS also used commons-* JARs. I guess this issue must have been resolved in many WAS in market. The other reason I discussed with Alex was that commons-* projects sometimes introduces the change of behavior between minor version-ups, and it produces unexpected bugs. It makes sense, but it think this is a matter of trust for other projects. I think we cannot say less dependency is a good thing IMHO.
BTW I had to fork NIO ByteBuffer because it was really hard to extend java.nio.ByteBuffer. :) I think we took care of this right? If there are objections please reopen this issue. Thanks.
We have no more StringUtils class. It has been merged with StringTools. -> closed
|
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Minor
StringUtils & StringTools
