This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, I am planning to start new J2EE Project for a team of 30 Developers. Could some one share the experience of leading a J2EE Project which is developed with using as much as latest technologies and best patterns and principles. 1) Source Code Directory Structure & Oraganization 2) Devlopment Tools , IDE, Software Components 3) List of components used like JSP , EJB, JDBC, XML , JMS, Webservices 4) I want to make it internationalised 5) I want to develop the code for multi Datbases 6) I want this application to be ready to deploy on any App Server. In short, I am looking for a best design / Architecture / FrameWork which are industry standard. I want to give exposure to latest technologies to my developers. Please provide with examples and samples wherever applicable for better understanding...
-Thanks For your Time & Patience & Help -Mark Clifford
It would be useful to know more about what kind of project it is, since that would affect a lot of the decisions. The biggest Java project I've led had only half a dozen developers, and that was a couple years ago, but I'll give you my thoughts. It was a web site. 1) Source Code Directory Structure & Oraganization The Java portion of your source code tree will be dictated by Java's requirement that the directory structure reflect the package structure of the code. Significant code modules will probably be written as packages, so that will determine their subdirectory structure. You may want to group utilities together into a package, or common code into a package, or whatever, for ease of access. Code that is not strictly Java code should be separated from the Java code at a high level in the directory structure. Keeping unit tests in the same directories as the code they are testing worked better for us than keeping it in a separate tree. 2) Devlopment Tools , IDE, Software Components The nice thing about Java is its cross platform standardization. This meant that each developer could choose his own favorite development environment; my personal favorite is CodeWarrior on Mac OS X. This worked well for six developers, but I'm not sure it would scale well to 30. If you do this, you will need a few minimal coding standards. In particular, to avoid tab rot, you need to either (a) have everyone set their tabs to equal the same number of spaces or (b) prohibit tabs in source code, and require everyone to set their editors to insert spaces instead. My preferred solution is (b). 3) List of components used like JSP , EJB, JDBC, XML , JMS, Webservices We used JSP and JDBC from that list. JDBC was definitely the right choice. JSP is probably the right choice for larger projects, where its added discipline has advantages over more lenient scripting languages. We used Oracle as the database, which was also definitely a good decision once we got past the installation headaches - Oracle has very explicit error messages which can speed debugging by a lot. I haven't used Struts, but it looks like it may be a good framework for managing site navigation. 4) I want to make it internationalised Can't help on this one; we didn't use Java's internationalization capabilities much. 5) I want to develop the code for multi Datbases JDBC should help with that. You may still end up doing some SQL porting for each database, since SQL is still quite nonstandardized. 6) I want this application to be ready to deploy on any App Server. Well, if it's a J2EE project, it will have to be a Java application server, but that should be fine, since Java runs on so many different platforms.
Hi Mark, I know this isn't the answer you're looking for. I've lead and architected many (many!) J2EE projects from the technical side, so here's my $0.02 on the subject. In reality, which frameworks you select, what IDE you use, how exactly you organize your source repository, etc., aren't very important. What matters most is the people you have. So my advice is simple: hire the most experienced J2EE architects, team leads, & project managers you can possibly afford, and then ask them (not us) how they would tackle each of your six bullet points above (and more!) If your team doesn't have much experience in J2EE, then you must bring in outside help, either permanently or as consultants. Anyway, I feel it would be impossible to give you sound advice on important architectural decisions through a message board forum, even one as good as JavaRanch. -Ade Barkah