ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Cornell" <lawriecorn...@hotmail.com>
Subject Best Practices for J2EE Project Directory Structures
Date Tue, 11 Feb 2003 01:22:43 GMT
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


Mime
View raw message