ok, I'll take a stab then :) - directory names (target vs dist, resources vs conf)
conf always implyed to me things that were static, and configured the process of execution, resources feels more like a component of the product, which phases like generate-resources is when ti generates java files of its own..maybe a poor example but it helps me distingish between configuration of my running product and things that my product needs to run correctly. - the purpose of the /main folder under src (src/main/java vs src/java) I believe this is so that you can clearly have src/test/java for unit tests that are seperate from your primary source - placing tests under src (src/test vs test/testname/src) test code is src, and ought to be treated as such, at least imo...sorry if these seem like trite answers, they are not meant to be. I see the m2 sample layout as an evolution of sorts for java development. Having worked on this problem for a number of years at work, anything that promotes goo practices should be encouraged, and m2 highlights this ability to break things down into smaller and more managable parts. for instance: root/ root/project-apis root/source1 root/source2 root/servlets/ root/servlets/servlet1 root/servlets/servlet2 root/servlets/servlet3 root/servlets/servlet4 root/servlets/servlet5 root/servlets/servlet6 root/war1 root/war2 root/ejbs root/ear1 root/ear2 that is a pretty flat layout for a project, but instead of obfuscating the process of deployment into a build.xml or like minded file, it clearly shows that servlet6 is being packaged up and built right there. And leveraging the transitive dependenies of m2 the placement of the right jars and all that kinda stuff in your output is fairly well managed for you. all your interfaces can go in the api's which is shared with the two source bases, which can be pulled in or not for each of the servlets, which can be sourced in for the different wars, etc. maintaining a few topical pom files is much easier then maintaining one or more multi-purpose ant files..in my opinion at least. and my pet belief is that providing a clean simple way to create subprojects of independently building and deploying code will encourage good design. the less time developers spend having to manage the mechanism of building and deploying code the more time they can spend doing it. and its my personal belief that the developers should all be in part responsible for the maintanence of the build system, not one poor guy that would rather be a developer in the first place. :P that make sense? there is a healthy bit of my personal thoughts in there but I hope it makes you think a bit about it :) On 8/1/05, Manny Nainu <[EMAIL PROTECTED]> wrote: > Yes Jesse (for me, anyway!). > > -----Original Message----- > From: Jesse McConnell [mailto:[EMAIL PROTECTED] > Sent: Monday, August 01, 2005 12:01 PM > To: Maven Users List > Subject: Re: Maven Recommended Directory Structure > > this question for m2 layout? > > > On 8/1/05, Manny Nainu <[EMAIL PROTECTED]> wrote: > > Paul, > > This is an excellent question and one I'm struggling with too. I'm trying > > to > > follow a similar convention to SUN's but I know the Maven-ites have > another > > format that I can see has value but not sure where this leaves us with > best > > practices. I wanted to follow /dist /conf etc. I think you can change the > > project descriptor to get the effect you want but it would be nice to > know > > why MAVEN went with something different from well-defined blueprints etc. > > > > Thanks, > > Manny > > > > -----Original Message----- > > From: Paul Faulstich [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 01, 2005 10:52 AM > > To: [email protected] > > Subject: Maven Recommended Directory Structure > > > > I've been browsing through the archives looking for some documentation > > regarding the thought process that went into the Maven directory > > structure conventions, but haven't found much yet. > > > > We are restructuring one of our projects, and it would be helpful to be > > able to explain to others (and to understand myself) why Maven's > > recommendation differs from Sun's > > (http://java.sun.com/blueprints/code/projectconventions.html#92194). > > > > In particular: > > - directory names (target vs dist, resources vs conf) > > - the purpose of the /main folder under src (src/main/java vs src/java) > > - placing tests under src (src/test vs test/testname/src) > > > > If this is a dead horse, then please just point me to the discussions > > that already exist. > > > > Thanks, > > > > Paul > > > > -- > > Paul Faulstich > > Systems Analyst > > L.L. Bean, Inc. > > Freeport, ME 04033 > > (207) 552-2294 > > [EMAIL PROTECTED] > > www.llbean.com > > > > --------------------------------------------------------------------- > > 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] > > > > > > > -- > -- > jesse mcconnell > > --------------------------------------------------------------------- > 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] > > -- -- jesse mcconnell --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
