JEE5 Development Environment

Question

I've got a client who already has some applications in production and therefore has already made some decisions about what their production environment will be for this next project:

• Sun iPlanet 6.1 SP7 (w/ apache)
• JDK 1.6
• Oracle Weblogic 10 MP3
• Oracle 10g
• 1024-bit SSL

They also have some corporate standards for web apps:

• Tomcat
• Struts
• Compatibility with Safari, Firefox, IE6, IE7

I'm also told that this app will likely not need a full on JEE5 environment (probably only a web container), but will need to communicate with one hosted on a separate weblogic instance via client EJB's etc as well as perform various web service calls to other corporate services.

I've been given the task to make some decisions about what our development and test environments will look like for this new team (small, probably 2 or 3 people including me, but may grow over the coming months). I want to create one where people can use the IDE they love and have a good development experience on localhost, but still have a smooth path to deployment in a test environment, and then again to the production environment. My thinking is that on local workstations http is fine but the integration test server should look exactly like the production server, and all traffic should be https to make sure we are getting an accurate portrayal of what prod will be.

Knowing that devs local workstations will be highly varied and may be running Mac OS X 10.6 (Snow Leopard) or Windows 7 on their local workstations, but a common test server would also need to be spec'd out: what technology stack would give us a nice smooth path from local development, through test, and into production?

EDIT: Sorry, when I say technology stack I mean for example Ant + JBoss + Tomcat + Oracle XE vs. Maven + Geronimo + Derby. Basically a list of the concrete specification implementations that we will need to install on each development machine and the test server that gives us a flexible dev environment, and a smooth transition to test and production environments.

EDIT2: It's probably worth mentioning that this app, if it needs to persist any information at all (which I am assuming will be the case), whatever it is will definitely not be complicated. In all likelihood it will be something akin to a rudimentary product database.

Answer 1

Test environment should exactly replicate production. Also do performance testing on the Test Environment.If hardware is a concern and number of servers in the cluster need to be limited then create less number of servers on Test but do replicate the same env as you have on prod i.e to say iplanet (apache) + weblogic + oracle db so on....

As far as local environment is concerned you can use Tomcat (as you need only the web container), and for the ejb client you can bundle the jar and make remote calls (if you are making remote calls to some remote app).If you are making local calls via local ejbs then you will have to use weblogic in development on local box.

Try to use the same IDE(though its mostly a matter of choice of developers).As far as OS is concerned it doesnot matter since if you are using a compatible IDE you will be building the code from that only.

Also make sure that IDE is tightly couple with either tomcat (if you use that) or weblogic so as to run the code in debug mode.

One very important thing, first decide on a code structure and then checkin that in version control, so that from any ide the user checks in / checks out in the same structure.So that same structure is shared across all developers. Branch the code in cvs or version control in every release and then checkout from head.Also very important use a single build file and maintain a setup document to build the environment on local box. Also regarding Framework to use choose the one that you are most comfortable with in coding and maintenance.That way you will reduce the number of bugs in the code.Mostly nowadays people using Spring/Hibernate combination but it depends whether it suits your project. Hope this helps.

Answer 2

It's really not clear what exactly you're asking about when you say "technology stack", do you mean servers, libraries, build tools? Anyway, here are some flippant recommendations:

• Hudson for continuous integration
• Avoid maven unless you really, really need it. It lures you in like a siren with it's promise of declarative dependencies and convention over configuration, but the practice is very different from the theory
• Use Spring wherever possible in preference to the standard JSE/JEE APIs. In addition to the simpler APIs it also facilitates testability and AOP features that are a lot easier than working with AspectJ directly. Of course, it also provides dependency injection which supports loose coupling
• Hibernate for ORM, or if your persistency requirements are very simple, Spring-JDBC may be enough

Answer 3

I would go for:

1. Hudson for nightly builds (or for every checkin)
2. Mercurial or Subversion for source control (works great on both Windows and Mac)
3. Spring, Spring, Spring. Yes I am serious, Spring solves many more problems than just dependency injection; like security, batch processing, transactions handling, system integration.
4. EclipseLink for ORM. It's many advanced features (that Hibernate lacks) have often saved me (like decent Stored procedure support).
5. A light weight container like Jetty, Tomcat or Resin. You are going to commit teamicide if you use heavy slow stuff like Geronimo or JBoss.
6. DeltaWalker for merge/diff tool (again works on all platforms).
7. If you are going to use advanced database features then go for OracleXE (and SQLDeveloper). Both are nice tools. If not then something light like H2 or Derby is fine.
8. JUnit (or TestNG) and Mockito for unit testing/mocking.
9. Please don't use Struts. Seriously, at least go with Struts2 or preferably something like JSF2, Stripes or GWT.
10. A decent bugtracker like, JTrac, RedMine or FogBugz
11. Selenium for integration testing
12. Sonar for code quality

If you are going to use different IDEs then Maven might be a good idea, since it allows each IDE to be configured from the pom.xml (works great in IntelliJ/NetBeans). But the best advice I can give you is this.

• Go with what you already know and have experience with. You do not transit from Struts to JSF2 overnight.
• Get the best tools you can get, seriously free stuff is not always the way to go (although it often is).

Happy hacking