How do I use JBoss with Eclipse/Netbeans in a group environm

[afshad]

Hi
Using JBoss and netbeans/eclipse.
Most of the getting started examples relate to an environment where only one person is developing and deploying. What about a team of developers working on the same project? Is there any guide or tutorial that can demonstrate the best practices for such situations. I need to learn about where to keep the source code in such cases so that everyone can see it. How the individuals modules like EJBs (entity bean or session bean) can be made part of the bigger work space.
Lets say if someone creates a new entity bean. How is it deployed. Is it deployed as part of the whole project or individually?
If we are working on different JSPs then how do we integrate all our work into the same workspace.
Is it possible for different people to use different IDEs?
I hope my concern is not too confusing. I just want to know how to setup the enviroment for all the developes.

Thanks!

[peterj]

A couple of suggestions:

1) All source code must be stored in a source control system (CVS, Subversion, etc.)
2) Everyone checks out the code from the source control system, makes changes, and checks the code back in.
3) Official builds are done directly from the source control system on a machine dedicated to that task. Official builds are never done on a developer's workstation.
4) Developers can use any IDE (or VI if they really want) to edit and test the code, as long as they follow point 2. I, however, am a dictator. I enforce that all developers use the same version of Eclipse with a specific set of plug-ins, and a specific configuration, especially for code formatting and compiler warning levels. I insist that all code checked into the version control system is formatted properly (just hit ctrl-shift-f), that CheckStyle has been run, and that no compiler or CheckStyle warnings are present. This ensures that all code looks reasonably the same, and meets minimal correctness criteria.
5) Developers can deploy the code that they are developing to their own copy of JBoss for their own testing. Note that this is not the production version of JBoss. No developer is ever allowed to update the production version of JBoss.
6) After an official build (see point 3) is done, the build is tested. It helps to have a testing team dedicated to this but in a smaller organization sometimes one or more of the developers must step out of development mode and assume testing mode. If you have developers doing testing, you must make sure that you clearly define what testers do, what developers do, and enforce that while in tester mode that people stick to what tester tasks are. For example, when a tester notices a bug, the tester reports the bug (using Bugzilla or other such tool, for small developments a spreadsheet works fine), the tester never ever fixes the bug.
7) Once the testing is complete and has passed (you need to define what 'passed' means, for example, 'no serious bugs, no more that 5 minor bugs, and 99.99% of the unit tests passed?) then you can deploy the build to the production version of JBoss.

[afshad]

Hi Peter,
Thanks for the suggestion. However you have stated that :
>>>>>>>>
5) Developers can deploy the code that they are developing to their own copy of JBoss for their own testing. Note that this is not the production version of JBoss. No developer is ever allowed to update the production version of JBoss.
>>>>>>>>

Say for instance I am developing a J2EE web based application with beans and jsp pages. In that case people working on the gui would also need to install jboss on their machines and configure completely just to test some html changes they have made??

Thanks,
Afshad
-

[peterj]

A couple of thoughts on that.

- You don't want user interface developers modifying the production version of the app any more than you want app developers doing so.

- You could use a framework such a Tapestry that provides clear separation between user interface and application code. The user interface developers could then develope the user interface separately from the full application and would need only an http server to test their changes.

- Considering that JBoss is not difficult to install or maintain, I don't see why the user interface developers could not have JBoss on their PC. (You could also provide a centralized machine running a development version of the app, but then you will need to do remote deployment of code changes and other "fun" things, so it probably is not worth it in the end.)

[tsar_bomba]

"PeterJ" wrote:

- You could use a framework such a Tapestry that provides clear separation between user interface and application code.

Or even better, Wicket ;)