On Thu, 8 Sep 2005, Ashley Williams wrote: Just a short comment on this: your developers don't care about which artifacts are produced and what's in them. But they don't see that each package is a separate jar, and has specific dependencies on other packages, usually versioned (probably not in your case..?)
The risk of having 1 big sourcetree for different artifacts is that you can't see the dependencies between the packages easily; i.e. if you're working in an IDE you can just use any class available, so dependencies can become spaghetti easily. In eclipse you can't even create multiple projects that share the same sourcetree with an includes/excludes filter. By splitting the packages up into standalone source trees you can force dependencies between them. Plus you can't freeze a version for one team when the other team is working on a package, unless you check out different versions for each package subtree. But all this is probably not a concern :) Just my 2 cents, -- Kenney > Ah, I think I see what your reading from my comments and I don't mean > what you're thinking, ie not producing separate patchable jars and > having one monolithic build file. That would be suicide! > > Just to be clear what I'm saying, those single file system projects I > have worked on are absolutely split up into components that can be > used in other projects and build and tested separately and self > contained- they are just jar files. However this is achieved solely > by the package name, ie everything under that package is one > component eg > > com > ----acme > --------gui (gui.jar) > --------model (model.jar) > --------util (util.jar) > > So only the deployers know that their jar files map onto the above > packages, but the developers don't even care. They're just worried > about the code tree. I don't know the experiences of folk here, but > the details of the build files are of little consequence to about 90% > of developers on a project, other than the fact that there is this > funny build file that has to complete successfully before you are > allowed to check in. Relative to Maven I'm the same: I really don't > care which jar file contains the plugin class that's throwing an > exception, I just want to find it quickly by pressing (shift+apple+n) > so that I can see what the problem is. > > What I've been trying to do is to place a pom where you see a jar so > that you could instantly see which packages correspond to deployable > elements at a glance. > > A horror story for you: I worked on one project where the build.xml > file was autogenerated by velocity and was over 3000 line long and > growing. Every time you added a top level package to your source tree > it would grow some more by copying a set of tags at the end. > Eventually there was noone on the project left that knew much about > how it worked! > > Honestly though I don't wish to advocate one way over the other. > > On 8 Sep 2005, at 16:28, John Casey wrote: > > > -----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] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
