Hi Jesse, Thanks for restarting this thread!
See below > -----Original Message----- > From: Jesse McConnell [mailto:[EMAIL PROTECTED] > Sent: lundi 7 novembre 2005 20:00 > To: Maven Developers List > Subject: Re: [M2][Proposal] J2EE builds best practices and conventions > > 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) Cool :-) > 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.. Could you explain what the dropit-*-servlet projects are? Shouldn't they be located in the dropit-war project? > 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 +1 > or go for the gusto? > > ear/wars/dropit-frontend > ear/wars/dropit-backend I don't think this can be considered a best practice. It may happen in very particular circumstances that it'll work but not generally speaking. That's because the same jar/war/etc can be packaged into different wars, ears, etc. Also it sounds very weird to me to have a directory structure like: My project |_ src/... |_ pom.xml |_ dropit-frontend/ |_ dropit-backend/ Mixing src/ and subprojects at the same level doesn't resonate too well I think. > 2. if we follow another common approach of nesting > > component/dropit What is this dropit project inside component? > component/dropit-logging > component/dropit-config > packaging/war/dropit-frontend > packaging/war/dropit-backdoor > packaging/dropit (type ear, generates dropit-1.0.ear) For me a jar, war, rar, even ear are all the same: they are modules (aka components). > 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... Yep agreed. I don't like it either. I prefer the directory layout I had proposed in my earlier posts. > 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 Yes, I fine with this too except that I'd name it a bit differently: dropit/ |_ logging/ |_ config/ |_ interfaces-api/ |_ frontend-servlet/ |_ backend-servlet/ |_ war/ |_ ear/ But again this is a very simple project that doesn't have everything automated? What about functional tests? Where do they fit? What about container configuration files? What about deployment to the container? What about database start/stop/loading of data? Etc... This is why I was suggesting an additional directory level in my previous posts: dropit/ |_ components/ |_ [...] |_ applications/ |_ [...] But I agree that if, as a user, you don't want to automate all those then a single directory level is enough. > 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). Agreed. > 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... +1 > 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. I'd treat jars in the same manner as wars, ejbs, ears, etc. > 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. Not sure about this naming conventions. > 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? :) Sure, it does! But it doesn't cover the full story. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
