J2EE Application Recommended Directory Structure

[ozgwei]

Hi all,

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

Or does your company structure J2EE application projects in
IDE-specific way, such as Eclipse?

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.

My company is about to start a new web application. Our architect
strictly follows all recommendations from SUN. I'd like to explore if
there are better ways to structure project directories.

Please share your opinions...

Thanks!

 

[Mike Beaty]

One way we/I differ is that we put the JSP folder in the WEB-INF
directory and only use struts/tiles to access the JSPs. It also seems
like a lot of layers above what you will actually be working on. I
usually just use the default file structure layout for apps that is
created by Eclipse/WSAD.

-Mike

 

[Manish Pandit]

Hi,

Some part of this structure is J2EE-enforced - like WEB-INF and tag
directories. Other folders can be application specific (like tests,
external settings and configuration for build scripts). As long as you
have a way to isolate and structure your source, test-source,
dependencies and binaries, it would be alright. Regarding JSPs, there
is normally a debate between making subfolders in WEB-INF vs. in the
webapp root. If you plan on serving all your JSPs via struts or a
similar framework, you can choose to put them in subfolders within
WEB-INF. That will guarantee no one touches your JSPs directly.

-cheers,
Manish

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

Or does your company structure J2EE application projects in
IDE-specific way, such as Eclipse?

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.

My company is about to start a new web application. Our architect
strictly follows all recommendations from SUN. I'd like to explore if
there are better ways to structure project directories.

Something not identical but similar.

It is not really that complex.

It does not require that big a set of apps before
you need something of this complexity.

Arne

 

[Lew]

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.

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
..

ozgwei wrote:
Something not identical but similar.

I like this answer; it implies that one should thoughtfully consider the
guidelines and one's decision.