"Can you please set up a default Java development environment for us?", my boss asked me a while ago.  That's a pretty difficult question, because where I come from, everyone is allowed to set up his or her own environment. Some people use NetBeans, others use a old version of Eclipse while others use the newest beta version of Eclipse with all possible plugins installed. Everyone should be able to customize his or her tools as they see fit. But I do agree, there should be some consistency across developers and projects.

So I started to set up a new fresh Java project with several goals in mind:

• Create a play environment to learn web development and server development for the java certifications, mostly the web components and business components certifications.
• Make a setup which can be used as a template for future projects.
• Test my ability to start a project from scratch, which I have never done before.
• Test the tooling of Eclipse to help me do it.

The Project

I decided to start a small web application which used a Stripes front end, a JPA/Hibernate domain model and an EJB3 backend. As I said, I never started a project before, so I asked Eclipse to help me. The normal way to organise these things in Eclipse is to have a separate project for each layer in the same workspace. I created these projects:

• A Dynamic Web project
  Holds the webpages and the view code logic. Simple applications can be implemented in only this project.
• An EJB project
  Holds the business layer of the application, the Enterprise Beans, is completely independent of the view layer.
• An EJB Client project (gets created by the EJB project)
  Defines the interface of the business layer used by the view layer. Also contains the JPA Entity classes and the value objects, which are used in the interface of the business layer.
• An Enterprise Application Project
  Does not contain any code, but wraps the other 3 projects together in an .ear file to be deployed on a J2EE application server.

This setup compiles and packages the files in the correct manner and deploys it to the J2EE server configured in Eclipse. This is all nice and simple, but this removes the ability for a developer to set up his or her own environment because the build process is now dependent on Eclipse, the environment. So I created an Ant build script to build, package and deploy the whole project without Eclipse. I also could have used Maven, but my experience with Maven is that it is slow to build and hard to configure and even harder to track down problems when they exist. Also missing dependencies, old online repositories and different versions causing problems made me choose for Ant.

Building and Deploying

I think the manner Eclipse chooses to setup of these kind configurations is pretty smart. To be able to build another kind of web front on the same backend, one only has to switch out the web project, tweak the ear project to package the new web project and everything should work. It is also possible to build a Swing client or some webservice, all using the same backend. So I tried mimic this approach in the ant script.

Short interlude: an ear file is an enterprise archive, which contains other archives which when combined consist of an application which can run on an application server, like JBoss, Geronimo, Glashfish and others. The other archives are jars and wars, which are Java archives or web archives. A Java archive contains java classes and configuration files, and can contain enterprise java beans of various sorts and normal Java code. Web archives contain web pages in the form of servlets, which can be a jsp pages or other static content and can also include normal Java classes.

Each project has its own ant script which builds the project and places an .jar or a .war file in the 'dist' folder of the project. The ear project has a special ant script which invokes the other scripts and packages the created .war and .jar files in an .ear file. The ear script decides on which projects to call (so the developer can rename the projects or check them out to a different directory) on a '.ant-global.properties' file, which should be present in the workspace directory. This file also holds a reference to the JBoss instance, so the ear file can be deployed by the script as well.

Importing Libraries in Eclipse and Ant

Applications build on a J2EE platform depend on many libraries. This are jar files which hold common code used by the system, for example logging, Hibernate and Stripes. In the past, projects had different ways to acquire the correct libraries used by the application. When Maven was used, they would let Maven handle these dependencies, which would work correctly, until the repository was not available anymore. Also checking these dependencies would take ages every time the project would be build. Other projects used Ant to checkout the used libraries from a special library project which would hold all the libraries for each project.
Eclipse uses the reference to the application server to reference all its libraries. So I realized I don't need to download 20+ jar files in my build script somehow, I can use the ones in the JBoss server. And I also have a reference to the JBoss environment for the deploy feature of my script. Now I only have to manage the libraries which are not bundled in application servers, which are not many. So far I have the JSTL core library and the Stripes library in the application, and for now I just check those in the repository so they are downloaded and managed directly with the project. Only problem is duplicate entries of the same jar file in many future projects, but as disk space becomes cheaper almost every minute, this won't be a problem for now, or maybe ever.