maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Faulstich" <pfaulst...@llbean.com>
Subject RE: Maven Recommended Directory Structure
Date Mon, 01 Aug 2005 18:18:19 GMT
Thanks Jesse.  I also was looking at m2, since we're not yet knee-deep
in maven.  Your comments are helpful.

Is this structure pretty much your creation, or did it come to be after
much group discussion, mud-slinging, etc?  okay, hopefully no
mudslinging :)   Unfortunately, I don't get to ask this same question to
Sun, and I very much suspect that the answer for them is "because that's
how ${some.experienced.user} does it."

Where would you envision things like environment properties that define
JNDI settings, etc, that are very static and are unique to each
deployment environment?

I tend to like your structure (although "target" seems like an odd
replacement for "dist").  It expands nicely where necessary.  Below I've
shown it for something that might have associated database structures,
and even perl or shell batch processing that runs maintenance jobs.

root/
+- some-component
|  +- src/
|  |  +- main/
|  |  |  +- java/
|  |  |  |  +- ...
|  |  |  +- resources/
|  |  |  |  +- ...
|  |  |  +- database/
|  |  |  |  +- ddl/
|  |  |  |  |  +- ...
|  |  |  |  +- stored_procs/
|  |  |  |     +- ...
|  |  |  +- perl/
|  |  |  |     +- ...
|  |  |  +- shell/
|  |  |        +- ...
|  |  +- test/
|  |  |  +- java/
|  |  |  |  +- ...
|  |  |  +- resources/
|  |  |     +- ...
|  |  +- site/   
|  |     +- xdoc/
|  |        +- ...
|  +- target/  
|  |  +- ...
|  +- docs/  
|  |  +- requirements/
|  |  |  +- ...
|  |  +  use_cases/
|  |  |  +- ...
|  |  +  stories/
|  |  |  +- ...
|  |  +- models/
|  |  |  +- ...
+- another-component
|  +-...
 

- Paul

-----Original Message-----
From: Jesse McConnell [mailto:jesse.mailing.lists@gmail.com] 
Sent: Monday, August 01, 2005 12:42 PM
To: Maven Users List
Subject: Re: Maven Recommended Directory Structure

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 :)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message