ok, digging this old thing out the dust bin.. I have abandoned my old layout (and the current structure provided by the j2ee archetype) and shifting towards something that is more like the current state of the maven repo...and I am trying to decide the lvl of nesting that is useful for the components when factoring vincents threads above..
first off, I concede the usefulness of having actual source in the war files...while my architecture doesn't really require/use that kinda thing, it would be silly to design around the idea in any sort of best practices way :) (that being that war's and the like don't need any compiled source at all, just suck in the associated dependencies) ok...I'll start with the basics of the maven layout since that is a pretty simple no brainer place to start..and for this discussion to make sense as a best practices discussion I'll invent a little project and if it makes sense to later we can apply the daytrader app to it (I don't know enough of the daytrader to do it justice atm). I know brett alluded to an exercise like this in the initial mail above.. Lets say we have a mythical project called dropit... flat: dropit dropit-logging dropit-config dropit-interfaces dropit-frontend-servlet dropit-backdoor-servlet dropit-site dropit-war dropit-ear pretty simple project, three discrete source modules with a seperate interfaces module for other systems to program against..the site, a war and an ear.. starting simple I guess there are a couple of questions we ought to answer if we want to arrive at a best practice module layout... 1. do we want to distingish wars, servlets, ears and other packaging concepts by the name of the directory or by nesting them? if so, how many lvls deep? dropit (the primary source, sister element) wars wars/dropit-frontend wars/dropit-backdoor or go for the gusto? ear/wars/dropit-frontend ear/wars/dropit-backend 2. if we follow another common approach of nesting component/dropit component/dropit-logging component/dropit-config packaging/war/dropit-frontend packaging/war/dropit-backdoor packaging/dropit (type ear, generates dropit-1.0.ear) this kinda approach still kind of rubs me raw with there being actual source in the wars since that means you have source under packaging subprojects... now we can move on to my personal psychosis :) I think my personal problem with trying to figure out a nice clean module layout is that with maven's multiproject abilities it makes it difficult to seperate my previous layout experiences stemming from one overriding build.xml file containing everything woven together, from the more clean seperation of discrete units that maven2 encourages...working through the repository for unit artifacts as opposed to other directories in the project really frees things up a lot. to be honest, working out my current setup and reading through the backlog of this message I find myself leaning towards a best practices j2ee setup of very close to the maven-components one, just utilizing a naming convention for j2ee components. dropit dropit-logging dropit-config dropit-interfaces-api dropit-frontend-servlet dropit-backdoor-servlet dropit-war dropit-ear For a simple project like this, there is no need to venture into lots of convoluted subdirectories that carry along a meaning with them (like the packaging thing and my hangup with there being source in there). I would even go so far as to say that if this where a best practices layout that a general rule of thumb could be that if you have 5 or more *-servlet artifacts that you nest them into a servlets directory dropit dropit-logging dropit-config dropit-interfaces-api servlets/dropit-frontend-servlet servlets/dropit-backdoor-servlet servlets/dropit-fun-servlet servlets/dropit-silly-servlet servlets/dropit-humor-servlet dropit-war dropit-ear and the same thing would hold for the ejbs, wars, ears, whatever...the only exception being artifacts that compile to be jars...then would all exist at the root of the project directory unless it really makes sense to nest components that have maybe 5 or more of a particular thing. which...when you look at it like this closely models the current structure of the maven-components svn module and how maven-plugins was nested in it with a whole lot of plugins in it. Perhaps we don't necessarily want to promote a j2ee best practices layout beyond a general rule of thumb for maven2 projects having all discrete compiling units at the base directory of the project. That and a suggested naming convention and nesting convention for j2ee artifacts -war, -ear, -ejb. that accomplishs a lot: 1) it gets us out of the old habit of nesting things just to nest things 2) promotes the concept that a project is made up of a lot of discretely compiling dependencies 3) holds all artifacts as equals, nesting only based on shared underlying functionality 4) all 'best practices' for maven2 archetype projects are the same...they already have an established layout internal to the sub-project, src, target,etc.. 5) best practices for different meta project organizations is reduced to naming conventions, j2ee using -war, -ejb, -ear...others can follow their own setups... 6) following this kinda approach ties closely with the multi-project setup...embraces the flatness really...maybe making it easier to explain how inner project dependencies work without any sort of implied knowledge based on project directory layout... does this rambling make any sense to anyone else? :) jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
