Re: J2EE Application Recommended Directory Structure
Arne Vajh?j wrote:
I would like to know how many companies you work for are following the
recommended directory structure for J2EE applications, as explained in
the following link:
http://java.sun.com/blueprints/code/projectconventions.html
A simpler way for apps that don't use EJBs:
Source:
http://tomcat.apache.org/tomcat-5.5-doc/appdev/source.html
Sun shows (nearly) this one also:
http://java.sun.com/blueprints/code/projectconventions.html#23136
..
Observe that the latter corresponds to the myapp1-war subtree of Sun's EJB
source structure.
There is some grey in deciding whether to put JARs in projectsource/lib/ or
projectsource/web/WEB-INF/lib/. I like both. I guess that Sun has some way
of choosing one over the other, since they show both, but I pick just one for
any given project.
Deployment:
http://tomcat.apache.org/tomcat-5.5-doc/appdev/deployment.html
Deployment is required to follow the standard pretty much exactly, except for
the aforementioned decision of where to place the JSPs.
Or does your company structure J2EE application projects in
IDE-specific way, such as Eclipse?
That would be a Bad Idea. The IDE should not determine the structure of the
app. Eclipse actually permits several ways to organize source, according to
whether it's a full-blown EJB-based project, Web project or "dynamic Web"
project, and gives the developer further options within those structures.
Netbeans starts off by giving one a choice of the Apache way or the Sun Java
Blueprints way. emacs doesn't impose any structure.
In fact, one really shouldn't standardize on the IDE, IMHO. Better is to let
each programmer use the IDE or editor that works best for them. You get more
productive programmers and much less risk of IDE dependencies in the product.
*Much* less risk. Eclipse, for example, is smart enough to resolve some
library classpath issues for you that would then crop up in deployment.
I've been on projects where the repository is organized the Apache (or Sun)
way for source, but the import into Eclipse warps into the Eclipse way:
project/src => project/JavaSource/
project/web => project/WebContent/
project/lib => project/WebContent/WEB-INF/lib/
This was handled by mapping the Eclipse directories to the repository via
Eclipse's interface with the repository software, the equivalent of
cvs checkout -d eclipsedir repositorydir
..
Personally, I think Sun's recommendation is only relevant for very huge
projects. For a typical J2EE Web application with local EJBs, this
approach seems over architected.
ozgwei wrote:
Something not identical but similar.
I like this answer; it implies that one should thoughtfully consider the
guidelines and one's decision.
It is not really that complex.
It does not require that big a set of apps before
you need something of this complexity.