On Tue, Sep 9, 2008 at 10:54 PM, Luciano Resende <[EMAIL PROTECTED]>wrote:
> In this scenario, where we have a contrib folder at same level as > modules and it part of the main build, how can we two goals I > mentioned ? > > >> The main goal for the clean up is to reduce amount of code users will > >> download and a step towards reducing our build time. > Those would be great, especially reducing the build time. I've looked at this before and think there are things we can do, its not a trivial amount of work but if others are interested now then I'd happily help try to make it happen. I don't think moving those two small modules out of trunk will help though, implementation-openjpa isn't even included in the build at the moment so isn't slowing things down :) We should start separate threads for those two things but i'll throw out some observations here: - The mortgage-loanapproval demo mortgage_diagrams.doc is the single biggest contibutor to the size of the src distro at a 8.5% of the total size, and all the doc in that one demo makes up a wooping 18% of the src distro size. The foo.png in the recursive itest is the next biggest contributor at 2.1% of the src distro size, so tidying up those two alone could reduce the total src distro by size by 20%. (those are sizes on disk not packed size in the archive but the percentages might be similar). - The binary distro size is vastly due to all the dependency jars (75%) and there's a top few dependencies that take up a significant part of that - script languages are big so not distributing say python and ruby would make a vastly bigger difference than deleting any/many of the tuscany modules, and there are other dependencys we could find ways not to need, even the smaller ones, eg, should we really have both asm and cglib as tuscany-core dependencies when both do the same thing and both are much much bigger than any tuscany module? - If you look at the reactor summary at the end of a build it gives the time taken to build each module so you can see where the time is going. Investigating things like why the alert agregator demo build takes so long would make much more of a difference than removing any of the small tuscany modules. And there are many tests which could probably be speeded up - eg use a single startup of the runtime instead of many, explicitly waking up the client instead of just waiting 10 seconds for a service to have been run etc. How about creating a branch, with the current trunk structure so we > have all modules archived and make some of these changes. Is this an > option that people would feel comfortable with? > I'm not so keen on a contrib branch as it would just becoming a dumping ground with code quickly going stale not being part of the build. The implementation-openjpa module was a contibution and not even from that long ago so wouldn't it be good if we could help make it better and use it more? Seems a shame to just delete it or moving it out of the main build as that isn't going to encourage people to contribute things. JPA support in Tuscany would be good wouldn't it? ...ant
