ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From loic.lefe...@bnpparibas.com
Subject Réf. : Best Practices for J2EE Project Directory Structures
Date Tue, 11 Feb 2003 10:07:25 GMT

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
lawriecornell@hotmail.com - 11/02/2003 02:22


Veuillez répondre à user@ant.apache.org
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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org










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.


Mime
View raw message