That's a good idea, I think the problem is how to sort out the required classes. we may have following options, 1, static analysis on src code/binary code, to pick up each *import*, *forName*, etc. 2, make a classloader to record all the classes it loaded when the application runs. 3, run as many application tests as we can then get the list of classes when have been used via --verbose.
Another choice is to make the grain bigger, from class to some pre-defined functional areas, it should be similar as the current modularity, users select the functional area they needed then harmony generates a minimized build for them. But first of all, we may need to remove the unnecessary dependency in each module. On 9/14/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > Guys, > > we are positioning modularity as one of the key benefits for Harmony. > And it is definitely one of the key benefits. > > But there is no simple way for Harmony users to define the list of > needed classes, jars and native libraries for their applications. > > So I suggest to create a tool which will create Harmony package with > the classes and native libraries used by concrete application or work > flow. First of all this application should collect data from one or > multiple application runs and then create a Harmony bundle without > unneeded classes and native code. > > Thoughts? Volunteers to help? :) > > SY, Alexey > -- Tony Wu China Software Development Lab, IBM
