-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline.
Cheers, john Ashley Williams wrote: | Hi John, | | Looking forward to the properties code btw It's in. Good luck! :) <snip/> | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | | |> Not sure I agree with your original assumptions. The java package |> namespace is one thing and the carving up into component jar files etc |> is another. The package namespace is monolithic whichever way you look |> at it, ie it's always going to be one package tree. Having one or many |> filesystem trees won't affect the source code authors one jot, but it |> will have an impact how the deployment team go about their business. Eg |> they will dictate that a certain file structure convenient for the jar |> command (multiple fs trees), or they will apply some filtering rules |> (single fs tree). Yeah I know, the deployer is just the coder in a |> different hat ;) Have you ever looked at the Spring source tree? Or the Eclipse one? While it might make complete sense browsing the class hierarchy in any of the jars created by either of these projects, trying to understand where these jars come from the source tree is an exercise in frustration. While the package namespace is monolithic, splitting these projects into pieces would provide a clear, targetted way of finding, building, and maybe patching/fixing the source code for a given jar. It makes parallel release cycles simpler, too, since the whole monolithic project doesn't have to pass tests in order to release a revision on one subset of the functionality. This isn't just a deployment issue, it's about the entire development approach. If you have multiple teams working on multiple deadlines which will result in releases of their respective code - potentially at different times - why would you want that code to reside in the same monolithic codebase? If you're assuming a single release cycle for all artifacts produced from that codebase, isn't it reasonable to assume that some of that huge codebase could be reused in different projects, and that that reuse might uncover patch scenarios and a separation of the release cycle for that artifact? If you don't have separate release cycles per artifact, the only other scenario I can think of for producing multiple artifacts is separation across a client/server type boundary...which is the only long-term legitimate use case for filtered compiles that I've heard, IMO. Short-term practicality notwithstanding, of course. :) | |> For me I don't care whether the code is in a database, single fs tree |> or multiple fs trees or even accessed through jndi, but I do disagree |> that splitting up your filing system along the lines of your component |> distribution is automatically a wise thing to do for any given project. Splitting of a codebase has the same pro- arguments as splitting up the java packaging structure. There may be reasons for putting all classes in the default package '.' but I haven't heard them...beyond the ever-present short-term need to "just get it working." I'm not making any assertion about automatic or absolute, just arguing from my own experiences. <snip/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDIFiNK3h2CZwO/4URAoxLAJ9uxhERzVelnCubCYQ+scfPxZ83qQCeLQlZ iRxxX7F1s5x/hA1fsIWaFm8= =Lsbu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
