The J2EE standard does not mandate the use of packaging. It is just a means of simplifying production deployment. And I agree, in the development phase, this encourages a monolithic approach to things - which is actually anti-J2EE because the point of having small worker units like EJBs is that they are stand-alone, encapsulated and well-defined in operation. EJB architecture encourages all the good things we want in software - modularity that displays strong cohesion and weak coupling.
The integrated tools for building J2EE components are the greatest source of problems. Many of these enforce a high-level packaging constraint to hide the problem of deployment dependencies, production packaging and so on. These are meant for small projects. We use a combination of NetBeans and JBoss for development. At development, we do not bundle multiple EJBs together for deployment. It gives us freedom to modify internals of an EJB and redeploy - they are small units, so they don't take a long time to deploy. Like dlls, in JBoss you can copy over an existing EJB and the new one gets redeployed in it's place. Ant scripts manage the process. JUnit integrates nicely into the IDE and we can unit test both shared libraries and EJBs. We use exploded WARs as well. We only copy over files that are changed, courtesy of Ant and we touch the web.xml. Deployment complete. Where necessary, we partition the web app so that certain sections operate independently for testing and development. And as WARs are the presentation layer, we have fairly light-weight coding in them in any case and they are mainly concerned with look-and-feel. For release, we then package the system for production deployment. Under J2EE, this is meant to be a task carried out by the deployment engineer, rather than an integrated part of development. Extreme programming encourages rapid prototyping but should not encourage what some more critical observers would call hacking (line by line changes until the unit works). The choice of deployment partitioning is just as much the responsibility of the developers and the architect as it has ever been. The choice of IDE is part of that decision chain. Choose the simple IDE that does everything without requiring thought is going to probably reap you the lowest common denominator results for large developments - but that is the trade-off. But that is my take on development and I am only a lowly practitioner of the craft, certainly no master. Regards, JonB -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivan Bolcina Sent: Friday, 20 June 2003 8:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Developing and debuging The worst part of J2EE in general,not only jboss specific, is debugging and testing <lapse>...</lapse> I believe this is due to compressed jars,wars, and ears. Also I agree to certain degree that it is better to fix a lot of stuff in one compile step,but it is also more demanding and so should not be mandatory. Some people are used to take one step at the time. Bye,ivan
smime.p7s
Description: S/MIME cryptographic signature
