ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <adam....@cyberspaceroad.com>
Subject Re: Best Practices for J2EE Project Directory Structures
Date Tue, 11 Feb 2003 08:47:31 GMT
There is definitely a good post on this subject in the list archives by 
one of the ant gurus, I think from early 2002.

I think the main question is whether you are working in a big or a small 
team. The java package construct allows the simple division of source 
code, and also on the front-end, the struts MVC framework (don't know if 
you're using it) now allows the easy configuration of sub-projects to 
cater for large projects.

Adam

Joel Riedesel wrote:
> 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
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 


Mime
View raw message