ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sascha Freitag" <frei...@objtec.com>
Subject RE: Best Practices for J2EE Project Directory Structures
Date Tue, 11 Feb 2003 08:56:05 GMT
Hi,

only a short answer in the form of a compressed explanation how we handle
our projects actually.
By definition all projects could have dependencies from each other (not
circular of course).
All projects have the same structure, which is:
-projectname/
	classes/
	build/
	conf/
	doc/
	src/
	gensrc/
If the project is web app, there is an additional folder called webapp.
This folder is mainly structured like the war.

All the jar, war and ear files are build into a lib directory one level
above the project. So for all the build scripts
building the classpath is the same.

In the build directory we have the build.xml for this project. This file
calls mainly other targets (of different ant scripts) out of our build
project, where we manage common build stuff. The third party jar's are also
managed by a seperate project.

A project is more a project in terms of IDE (eclipse). From the logics view,
it is a modul which delivers certain functionality.

I hope, that helps and is understandable.

I recommend to read the thread
http://marc.theaimsgroup.com/?t=104390191700001&r=1&w=2, this gives also
some answers of some of you questions.

Cheers Sascha

-----Original Message-----
From: Lawrence Cornell [mailto:lawriecornell@hotmail.com]
Sent: Dienstag, 11. Februar 2003 02:23
To: user@ant.apache.org
Subject: 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



Mime
View raw message