I think it's a general idea which applies to all the dependencies such as ICU, BouncyCastle, etc.
We need to understand one thing that is comparing to the side effect of folking the src code, what benefits we can harvest. another is whether they are allowed to be redistributed. It should be disscussed case by case, XML related you have mentioned that we can 1. rebuild them to the same bytecode level 2. make them more natural as harmony modules. ICU It's the one which I want to customize as soon as I can. With ability to change the src code and build, we can 1. remove the unnecessary cycle dependency from ICU code rather that a work around in harmony code. 2. Improve performance - this area is one of the worst against RI. 3. remove unnecessary data and duplicate charsets to reduce the disk/memory footprint BouncyCastle: A quick test shows that it consumes more memories than RI - still dont know why. but changes to the src code is definitely required to fix that. Also we can do customization to include basic algorithms into the core of Harmony Select which are just talking about to reduce the size and achieve better modulization. YOKO Anyone want to do this? BCEL do we still need that? I see ASM has been included. just to stimulate the discussion, need more thoughts. On Thu, Apr 30, 2009 at 8:50 AM, Nathan Beyer <ndbe...@apache.org> wrote: > I've been thinking about how we consume Xerces and Xalan, especially > since we've had to do some of the more recent modifications to the > build scripts to manipulate the JARs and archives in various ways. As > an alternative to grabbing the binary packages, we could grab the > source code itself and do our own builds. We could do this by grabbing > the officially distributed source archives or we could checkout the > code directly via svn:externals pointing to release tags (some risk in > that). > > One advantage this has is that the code would be compiled at the > bytecode level of our code (Xerces currently builds to support Java > 1.3). The other would be a more natural fit into the classlib module > structure, which would allow us to build and package manifests as well > as additional tests. > > Just something I've been knocking around in my head. Any comments or > additional thoughts? > -- Tony Wu China Software Development Lab, IBM
