I'm planning a small size j2ee-project (5 developers). It is our first project using j2ee.
Due to little practise I'm asking here for some advise or best-practise on how to setup up the cvs-project-tree especially how to separate the java-sources for client (application and web) and server (ejb, business logic, dao).
There are so many books, sites, forums about ejb-coding but so little about configuration management. Can anyone point me to some public available examples (ant build-scripts, cvs-directory-structure, testing, continuous integration, etc.).
I've read the jboss-starting guide but dont like the separation of java-files into client, servlet, and ejb-folders. Are there any better approaches?
PS: we are using jboss 3, cmp2.0, xdoclet and struts for webclient
I followed the structure described in the book "Ejb Design Patterns" (available in PDF from this site). It basically describes a tree as follows:
Create a root directory in CVS for your projects, say /projects/$PROJECT_NAME or something. We'll call that $PROJECT_ROOT.
Under that you create this structure:
src/java - This is where your source goes.
src/java/com/whatever/web - Webside only
src/java/com/whatever/ejb - ejb only
src/java/com/whatever/common - common stuff (e.g. data containers)
build/ - Makefiles or ant files go here
test/ - test case code goes here
archives/ - .jars that you generate as part of your build
archives/web - if you want do delineate further
archives/ejb - if you want do delineate further
archives/common - if you want do delineate further
lib/ - 3rd party jars that everyone needs
webapp/ - webapp resources (this looks like the root of an exploded .war file)
As far as deployment descriptors for EJBs, I would create a META-INF directory in the src/java subdirectory containing your EJBs. It also might behoove you to put each EJB in it's own package. Will make it easier to redeploy and manage your build process (plus easy to understand where to find files).
In terms of build targets, you want something to make all EJBs, make the entire web-app, compile every class file, and then some way to make an individual EJB (you will not want to wait to recompile all EJBs just because you changed one line of code). You will want to compile your classes into your webapp's classes directory, so the webapp can get them. The EJB deployment steps will result (presumably) in jar files you can deploy to the container, so unless you have a second client for your app, that should be good. You can also get fancy and have targets to stop/restart your app server(s), or to run test cases.
Test Cases: Even if you aren't doing XP, you should, at the very least, write test cases for you Session EJBs. The advantage of this (other than having automated tests) is that you can develop, deploy, and debug your EJBs w/out any part of the webapp existing, and it's also a great way to debug your build environment early in your process.
Ant vs. Make - Unless you know make, you are probably best sticking with Ant. The EJB Design Patterns book has some decent ant files in it that you can use as a base. If you are on UNIX and you know Make pretty well, that will be more flexible and result in a more pleasant development environment, but Make can be very complicated and has a steep learning curve.
IDEs - The above directory structure may not work well with certain IDEs, so you should modify it as necessary to make your lives easier. Command line folks probably won't care about the structure, but things like JBuilder will make more work for you if you don't do it their way, so get that straight from the get-go.
Hope this helps!
I would have to say that it greatly depends on the IDE that you are using and the appServer that you are using.
Some appServers allow you to work with an expanded ear, meaning you don't have to package it into an ear file for deployment, you simply point the appServer to the expanded ear.
IDEs like JBuilder7 will even compile your JSPs for you,but requires that you stick with their webapplication directory structure. So it really depends if you are going to use these types of features or not.
Personally, I prefer to spend a few more time creating a few ant targets that will do that for me and keep the directory structure the way is more convenient for us.
In anyway, you should have something that resembles the following: