ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Riedesel" <jriede...@jnana.com>
Subject Re: Best Practices for J2EE Project Directory Structures
Date Tue, 11 Feb 2003 01:35:23 GMT
Unfortunately, I believe you also need to have some
sort of structure for those app servers you are supporting
as well.  You tend to sometimes need a few different entries
in you ejb-jar.xml or web.xml files for the different
app servers and, more importantly, they all have their additional
'xml' files that must be packaged.

That's all only relevant if you are packaging an ear or something
that is ready to deploy and run directly in someone's app server.

Just my 2 cents.  I find it to be somewhat like supporting different
OSs.... :-).

Joel

----- Original Message -----
From: "Lawrence Cornell" <lawriecornell@hotmail.com>
To: <user@ant.apache.org>
Sent: Monday, February 10, 2003 6:22 PM
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