Take a look here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/manual/src/guide/examples/template/
It is a template used for J2EE projects under JBoss but it can be used for
others application servers :)
Cheer,
Loïc
Extranet
[EMAIL PROTECTED] - 11/02/2003 02:22
Veuillez répondre à [EMAIL PROTECTED]
Pour : user
cc :
Objet : Best Practices for J2EE Project Directory Structures
Hi All,
I was wondering if anyone had any views on best practices for directory
structures when developing J2EE projects that use EJBs?
The following directory names seem fairly standard so I'll adopt them for
this example (any comments?):
bin/ - Binaries, scripts, etc
build/ - Used for building the project
classes/
...
...
dist/ - Files for distribution (.ear, .war, .jar, etc)
doc/ - Manually created documentation
gen-src/ - Used for any generated source code, for example from XDoclet
java/
conf/
lib/ - Any dependency jar files required to build the project
src/
java/ - Java source code files (including servlets)
webapp/ - Web files: JSPs, HTML, gif, WEB-INF, etc
conf/ - Configuration files
test/ - test code
(As an aside: Do you find it easier to create the build directories/files
so
that they match the pattern expected for war, ear, etc, or do you find it
easier instead to code your Ant script to sort out which files need to go
where in the archive file (war, ear, jar)?)
And, finally, on to my two main queries:
1. What is the best way to organise Projects and Sub-Projects?
2. What is the best way to organise source code within these projects?
1. What is the best way to organise Projects and Sub-Projects?
==============================================================
Say we have a main project (e.g. HumanResourcesProject) and it has several
"sub"-projects (e.g. Payroll, PensionsAdmin, TrainingManagement,
Recruitment, etc). The actual problem domain is irrelevant - I just picked
HR as an example to illustrate my point - I am just interested really in
general rules of thumb.
Say also that the project and sub-projects share a dependency on another
project that is also used on by other projects (e.g. AppFramework) and also
they share a dependency on some code that is only used by this project
(e.g.
HRUtilities)
The way I see it, the options seem to vary from loosely coupled projects to
tightly coupled projects:
a) The project could each have their own copy of the tree. This seems like
it would offer maximum flexibility (in terms of source code management,
etc)
but looks like it could prove difficult to manage without some rigourously
enforced procedures / automation to ensure the projects all work together
as
a whole.
-Projects/
-HumanResourcesProject/
build.xml
+bin/
+build/
+src/
(etc)
-Payroll/
build.xml
+bin/
+build/
+src/
(etc)
-PensionsAdmin/
build.xml
+bin/
+build/
+src/
(etc)
(etc)
+HRUtilities/
+AppFramework/
b) Alternatively, you could just have just one instance of the bin and lib
directories across all the projects so that it is easier to keep the use of
these files in sync.
Projects/
-HumanResourcesProject/
build.xml - parent build file which calls the sub-project
builds files
+bin/
+build/
+src/
(etc)
-Payroll/
build.xml
-bin/
-build/
-src/
(etc)
-PensionsAdmin/
build.xml
-bin/
-build/
-src/
(etc)
(etc)
-HRUtilities/
build.xml
-bin/
-build/
-src/
(etc)
+AppFramework/
c) Or the sub-projects (which now, perhaps, would be better called modules
rather than projects) could all be moved to just be separate branches under
the same source tree and build directories.
-Projects/
-HumanResourcesProject/
build.xml
+bin/
-build/
-Payroll/
-PensionsAdmin/
(etc)
-src/
-Payroll/
+java/
+webapp/
+conf/
-PensionsAdmin/
+java/
+webapp/
+conf/
(etc)
-HRUtilities/
+java/
(etc)
+AppFramework/
d) Or, finally, the modules (formally sub-projects) could all be moved
under
the same source tree and just differentiated by their package names
-Projects/
-HumanResourcesProject/
build.xml
+bin/
+build/
-src/
-java/
-com/
-domain/
-hrproject/
+payroll/
+pensionsadmin/
+hrutilities/
(etc)
+webapp/
+conf/
(etc)
+AppFramework/
What is the best choice? What effects will each of these choices have? -
Any
ideas would be greatly appreciated
2. What is the best way to organise source code within these projects?
======================================================================
My question here is: Is there any benfit to be gained by sub-dividing the
source into separate directories / packages for the different application
layers, e.g. Presentation/Business/Integration or Client/Web/EJB/DAO, or
instead of by separating out by architectural layer what about by
architectural pattern e.g. Model/View/Controller? If so which of these have
you found to be the best option?
And where is the best place for the separation to occur?
Is it worth splitting the source directory into separate source directory
trees for each layer / pattern constituent? E.g.:
...
-src/
-Java/
-Model/
-com/
-domainname/
-projectname/
-model/
(etc)
-View/
-com/
-domainname/
-projectname/
-view/
(etc)
-Controller/
-com/
-domainname/
-projectname/
-controller/
(etc)
-Common/
-com/
-domainname/
-projectname/
-common/
(etc)
Or is sufficient to just separate out the code using the package names?
E.g.:
...
-src/
-Java/
-com/
-domainname/
-projectname/
-model/
(etc)
-view/
(etc)
-controller/
(etc)
-common/
(etc)
Or is there a better alternative?
I appreciate that much of this is down to personal preferences, and that
there are no right or wrong answers to a lot of my questions. I am sure
that
the value of any of these solutions depends on the size of projects you are
working on, and the size of the teams that are working on them. However, I
am interested in which styles you have found most flexible and easiest to
use in practice, and whether the more complex structures offer any real
world advantages.
Finally, apologies for the lengthiness of this post, and my thanks in
advance to anyone who takes the time to respond.
Regards,
Lawrie
_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://messenger.msn.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
