On Wed, Sep 10, 2008 at 7:59 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > 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 > > Hi My motivation for making the re-org proposal a while back was to clearly identify in trunk those modules that we feel are developed enough to be part of the distribution vs those that are not. A reaction at every release to having to guess what we should be releasing. It is also an opportunity to make it psychologically easier to create new modules in trunk.My though was more about providing a path for new modules rather than a place to retire old ones. I think having a separate branch for these kinds of modules will lead to them falling into disuse and will be more difficult to manage as I have to look in two places rather than one. Following on from Luciano's original thought, which I think is a good one, there are a couple of modules that I know could go. itest/domain is now pretty much redundant and modules/monitor-logging has now been pretty much replaced by the default monitor function and so, with a bit of recoding in itest/validation, it could be removed. Neither of these are holding the build up much though so +1 to futher optimization of the build is whatever way we can come up with. Simon
