Kenney, see my comments inline.Slight change of topic: I definitely think there is a big black hole that lies between an IDE and Maven - really push the integration aspect hard and I think Maven adoption would accelerate.
As if you guys aren't working hard enough already! Thanks - AW On 8 Sep 2005, at 19:10, Kenney Westerhof wrote:
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 thatyou 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 dependenciescan become spaghetti easily. In eclipse you can't even create multiple
Yes I have definitely experienced this phenomena! However we did get round this on my most recent project. I remember working away in intellij on a bugfix (all was fine) then going to check my code in only to find there was a build failure. I was soon put straight by the experienced members of the team since I was importing a class from an illegal jar file. The build files were such that the classpath only included legal dependencies. ie the filtering and dependencies were enforced by the ant scripts and not by the filing system.
projects that share the same sourcetree with an includes/excludes filter. By splitting the packages up into standalone source trees you can forcedependencies between them.
I've written a plugin that does just that. Each project points to the source root and just adds an includes filter for the specified artifact package.
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.
Not sure what you're describing here, but if my team isn't ready for the latest jar file I just stick at a dependency right? I probably don't understand your point though.
But all this is probably not a concern :) Just my 2 cents, -- KenneyAh, 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 understandwhere these jars come from the source tree is an exercise in frustration. While the package namespace is monolithic, splitting theseprojects into pieces would provide a clear, targetted way of finding,building, and maybe patching/fixing the source code for a given jar. Itmakes parallel release cycles simpler, too, since the whole monolithicproject doesn't have to pass tests in order to release a revision on onesubset of the functionality. This isn't just a deployment issue, it'sabout the entire development approach. If you have multiple teams working on multiple deadlines which will result in releases of theirrespective code - potentially at different times - why would you wantthat code to reside in the same monolithic codebase? If you're assuminga 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? Ifyou don't have separate release cycles per artifact, the only otherscenario I can think of for producing multiple artifacts is separationacross 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 thejava packaging structure. There may be reasons for putting all classesin the default package '.' but I haven't heard them...beyond theever-present short-term need to "just get it working." I'm not makingany 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
