I've cleaned up most of these now, of the remaining mike has said he'll do implemantaion-spring-xml, we're keeping assembly-xml and policy-xml for the time being, and that leaves: binding-ws-xml, contribution-xml, definitions-xml, implementation-java-xml, interface-java-xml. It turns out that those are not completely trivial to fix. I'd still like to fix those but its going to take a bit longer as some refactoring and plug points need to be done, I'll start some seperate threads about those. From this one comment below...
...ant On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng <[email protected]> wrote: > over-engineering. Meanwhile, I really don't think merging functionally > decoupled modules into a fat one is going to reduce spaghetti as it just > hides the spaghetti. My experience from trying to tidy up these up is that the opposite can be the case too - having lots of separate modules is sometimes what is hiding the spaghetti. Its easish to see where a single module is being used and what its dependencies are but its really quite hard to see that for collection of modules. A module may look like its functionally decoupled at first glance but its not until you actually trace all the links from other modules and modules its using that you find issues. We say we keep the model and runtime modules separate so you that can use them independently but no one does use them that way and we don't have any tests to verify that its possible - and it it turns out that its not possible. Having tried tidying up these modules shows in the end most of the runtime does get dragged in anyway and that its not really possible to use subsets of the modules like we expect. ...ant
