> > 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. >
ok, this is where you are losing me...what exactly are these extra directory structures gives us? You mention functional tests...is that was you are aggregating under the applications directory? This starts to get into the discussion we had a couple of months ago on irc in regards to the different testing methodologies to support under maven direction. The simplest is the surefire launched unit tests sitting in each subprojects src/test/java directory. Next up would be integration tests between different subprojects, different components in your above example...is that purpose of the applications directory? I think on that irc discussion this was about as far as we figure maven at this stage would try and formalize since post integration testing it get really localized to implementation... I would think that integration testing in a j2ee build, or any build really would just be another subproject that declared all of artifacts as dependencies. If you had too many different integration tests or wanted to break them out by functionality then adopt the same mechanism I mentioned earlier, name them function-integration, function2-integration, function3-integration...and if you get 5 or more then nest them in a directory called integration. what artifacts are you seeing will be produced in the applications directory? The war and ear artifacts? aren't they really just dependencies to other artifacts... if applications is where you are envisioning storing configuration or different containers and whatnot then I am not sure why that means that the component directory needs to nest everything else.. In your comment you mention starting and stopping the container and things..that almost sounds like a tools or utility functionality which I would just make a subproject for called deployment-tools or something...and in there either the pom that uses the relevant plugin or subprojects if there are multiple behaviours.. thanks for the response :) it looks like we are agreeing on a lot of the fundamentals which should let jason actually start writing about these things :P jesse On 11/14/05, Vincent Massol <[EMAIL PROTECTED]> wrote: > > 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] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
