2007/9/14, Tony Wu <[EMAIL PROTECTED]>: > 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. This approach is good for applications. Like Eclipse for example. But is not applicable for servers and other software of this type.
> 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. These two for servers :) > 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. Yes, we can select by classes or modules. Actually I think that we should implement both possibilities. > But first of all, we may need to remove the unnecessary dependency in each > module. Right. SY, Alexey > 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 >
