Each developer on his or her PC should use Eclipse and install JBoss Tools. Within Eclipse create a server and associate it with your web project. Then as you make changes they can be quickly synched with the server (the one declared in Eclipse). Then you can do your testing locally. This works well for most things, though occasionally you will have to restart the server.
Once you check your changes into source control, a continuous intergation package (such as Hudson) can do a full from-scratch build and deploy it to newly instantiated JBoss AS server configuration for testing.
I recommend against having JBoss AS read your JSP files from the source directory. If the only changes you are concerned with is JSP changes, then you could always use an Ant script (or a file sync utility) to copy the source files to the deployed directory.
Thanks for the suggestion. However, I don't want to be completely dependent on Eclipse (or even jBoss for that matter). I still want to be able to use Notepad++ with the command line (as well as eclipse). I also want to be prepared for when jBoss goes out of fashion.
I'm looking for best practices on structuring projects in a sensible manner.
I then want to configure jBoss to work with the projects.
Here's the spec for what I want :
1) js, css, images, html & jsp: I want jBoss to read these straight out of source control. When they change, I want jBoss to pick them up straight away without any manual deploying or synching. (DRY principle: I don't want multiple copies of any of these).
2) 3rd party jars: Again, I want jBoss to read these straight out of source control. However, these will rarely change and don't require hot deployment.
3) Servlets and java code specific to this web app: These will change regularly and need hot deployment.
4) Standalone java projects (eg libs & utils specific to the company). This code will change regularly and require hot deployment. This code must be kept separate as it may be common to other web apps also.
Regarding configuring jBoss, I've noticed that versions 4.2.3 and 5.0.1 are quite different.
Any info on the differences, wrt config, would be most welcome.
1) Not possible as state - there is nothing within JBoss AS that enables it to directly load the files from source control. You could possibly accomplish this with builds scripts hooked into a continuous integration server such as Hudson. Also, some of the files can appear external to a WAR (js, css, html as examples) while other need to appear within the confines of a WAR (jsp as an example), though the WAR can be exploded or packaged.
2) Again, not possible as stated. Personally, I prefer binary artifacts to be housed in a Maven-style repository (suc as Nexus). Once again, scripts could be employed to deploy updated binary artifacts. And realize again that most binary artifacts should be packaged within an EAR or WAR.
3) You could build depoloyment into the Ant or Maven build. Deployment to local JBoss AS on the developer's PC is easy. Deployment to test systems should be handled via continuous integration.
4) This question gets me thinking you haven't looked at Maven. Each binary artifact needs to have its own project, which implies its own build. And each binary artifact needs to idetify its dependencies on other binary artifacts. This can be easily managed with Maven.
By the way, I typically use Eclipse as a text editor. While I use Notepad++ and UltraEdit, I prefer editing Java code in Eclipse mainly because of the code completion, automatic formatting, refactoring support, and other niceties that Eclipse provides. For builds I always rely on Ant or Maven build scripts, never on Eclipse (well, except for Android development).
Regarding 4.2.3 vs 5.0.1 (actually, you should be using 5.1.0) config differences, the biggest differences is that a lot of things that were configured with MBeans (*-service.xml) in 4.2.3 are configured on microcontainer POJOs (*-jboss-beans.xml) in 5.x, and JBoss MQ was replaced with JBoss Messaging making messaging configuration completely different. But configuring data sources (*-ds.xml) and logging (jboss-log4j.xml) remained the same.