|
Mastering J2EE Application Development Series
 Step 2 of 12: Managing J2EE Projects
Master and Commander
by Julien Dubois
As a project manager, choosing among project management tools and practices are the most important decisions you will make
Starting a new J2EE project from scratch can be as challenging as it is exciting. The decisions you make at the earliest stages of a project will have tremendous consequences across the project's lifetime. For that reason, sound project management practices can often ensure a projects success or its failure, right from the outset.
If you're managing a J2EE project, there are at least six key project management questions for which you will need firm, unambiguous answers:
- "Which build tool should I use?"
- "How to make a group of people work together on a shared code-base?"
- "How do you I keep myself as well as my team members informed about the project's state?"
- "How can I reduce the build process to a single click?"
- "How do I simplify the management of multiple projects?"
- "How do I manage archives for J2EE software?"
In this article, I'll identify some of the actions that you, as project leader, can take (using open-source project management tools supported by Oracle JDeveloper) to answer these questions and make your project successful. I'll also offer a short tutorial to get you started on project and code management using Maven to create a ready-to-use, Struts-based project.
It is hard to do justice to all these topics in a single article, but my hope is that we will touch on some of the more important topics in sufficient detail to get you started.
Making the Choice
The build process is a key component in any J2EE project, and there are a number of build tools to choose from. For the purposes of this article, our discussion will be limited to two of the most popular J2EE build tools: Maven and Ant.
Maven and Ant are open-source projects from the Apache Software Foundation, and choosing between them is one of the most important decisions a project leader can make. Maven aims to help developers build, test, and document their Java projects easily and in a consistent way. It is a powerful tool, and it can very helpful for managing a project during its life cycle.
Ant is the most popular build tool in the Java world. It is a very flexible tool; however, this flexibility comes at a price. Many enterprise projects suffer from obese Ant scripts, which are difficult to manage after the build owner leaves the group.
To help you choose between these tools, here is a high-level comparison:
| | Ant | Maven |
| Installation | Very easy | Very easy (very similar to Ant) |
| Time to start a new project | 5 minutes | 15 minutes |
| Time to add a new functionality | 10 minutes to add a new target | 2 minutes to use a new goal |
| Time to learn for a new developer | 30 minutes. Very easy to understand, and very good tool support. | 2 hours. Can be confusing at the beginning. |
| Standard layout | No (which is good; you can do whatever you want). | Yes (which is good, all your projects will look the same). |
| Multi-project support | Yes, but you have to do your own master build file. | Yes, with the Maven Reactor |
| Documentation generation | No standard way to do it, but there are plenty of available tools. | Yes |
| IDE integration | Yes | Very basic |
My recommendation is to choose Ant if you know what you're doing and want absolute control over your build mechanism. However, if you are unsure about your project structure and do not have much experience with build systems, choose Maven. Maven will provide you with a good project layout and excellent tools to help you across the whole project life cycle.
By following this article and using Maven, you will end up with a good set of tools, good software processes, and a fine project layout. If, however, you wish to switch to Ant, it will be very easy to rewrite the Maven goals you use as Ant targets. For a simple build, switching from Maven to Ant is a couple of hours' work, so have no fear of being stuck with Maven for the rest of the project's lifetime.
Team Collaboration
The main asset that we deliver to the client is production-quality code. To meet that goal, it is critical that the whole team work together, and for this goal a range of Source Configuration Management (SCM) tools are available.
For example, the open-source Concurrent Version System (CVS) is probably the most popular SCM software around. It is installed by default on many Unix/Linux systems, and has a very good Windows version called CVSNT.
| "Switching between an IDE and a SCM tool is error-prone and time-consuming."
|
When starting your project, be sure that:
- Your IDE works well with your SCM system. Switching between an IDE and a SCM tool is error-prone and time-consuming, especially when you're managing thousands of source files. (Oracle JDeveloper fully supports CVS and provides a single window to work from; therefore, you can avoid switching between tools.)
- You understand the basic principles of SCM software, such as tags and branches.
- Your source code repository is backed up and is easy to access. If synchronizing code is too slow, developers won't use it.
- You have taught your developers how to use the system.
- You have instructed your developers to synchronize their code often.
The Maven Project Repository Maven's philosophy is to store only source files in the SCM system, and store libraries (such as struts.jar, log4j.jar, and so on) in the Maven repository, a remote directory in which files are stored by project and version. This task seems a little cumbersome at first, but managing a project's many dependencies is a daunting task that Maven solves in a rather elegant way.
As this article focuses on enterprise projects, you will probably want to create your own Maven repository. I highly recommend the use of Maven Proxy, which will connect, through your corporate firewall to the global Maven repositories on the Internet. When you have created your own corporate repository, you can store your own JAR files there easily. (The directory layout is obvious, just mimic the structure created by Maven Proxy.)
Maven also offers a plug-in called StatCVS, which produces a complete report of a project's CVS repository, including many graphics showing developers' activity.
The Maven Project Object Model (POM) Maven uses a Project Object Model (POM) to store a project's information. This information includes the project's name, description, developers, SCM system, and so on. The POM is a simple XML file, which is fully described at http://maven.apache.org/reference/project-descriptor.html.
As the POM is an XML file, you can edit it with Oracle JDeveloper. However, the Maven JDeveloper plug-in we will use later will remove the project.xml file from the current project — which is not such a big problem, as you can re-import it quickly.
Getting Feedback from the Project
Another key consideration point as you manage your J2EE project is that you want to be informed of the project's state. However, you don't have the time to verify each and every file developed or checked-in by your team.
The solution is to communicate with your team and use the right reporting tools.
Of course, the first thing to do is to hold regular meetings with the developers. However, feedback does not always have to be face-to-face. There is a wide range of automated reporting tools available— such as CruiseControl, JUnit, Checkstyle or StatCVS — that can keep you up-to-date on the project's current state. In this context it would be helpful to discuss the value of continuous integration and CruiseControl.
Using CruiseControl with Maven Continuous Integration is a best practice pioneered by Martin Fowler, which I would sum up as "It's a good idea to build and test a project automatically, at regular time intervals." This concept has been widely adopted by companies around the world.
Continuous Integration is particularly useful when several people are working together on the same project, as they will be regularly updated of the project's state and will receive emails from CruiseControl notifying them of their errors.
CruiseControl is the most popular Continuous Integration tool, and I recommend it heartily. CruiseControl is fully able to deal with Maven-managed projects. Maven also provides a plug-in for configuring CruiseControl. This plug-in can easily create a CruiseControl configuration file, and can also be "put in charge" of running CruiseControl.
Another useful Maven plug-in, Checkstyle, will help your project adhere to a coding standard. Checkstyle reports can be included into CruiseControl so that anyone committing non-standard code will break the build. To add those reports to your project documentation, just add them in your project.xml file, in the <reports/> section.
Managing the One-click Build/Deploy Cycle
Building and deploying the application can take several hours, and might require several manual steps. Developers are fed up with long build cycle times and the need for manual intervention. Several hours a day are spent waiting for the application to build and deploy. There are no words to describe the frustration of these delays.
The cure is to set up a "one-click build and deploy cycle" process. When used correctly, build tools such as Maven or Ant transform the build process to a single click in the developer's IDE. These tools can also automatically deploy a project to your application server of choice.
This solution has an added benefit: It not only improves eases developer's task, but once a neat process has been defined to package the application, the software delivered to the client will be of higher quality (no more forgotten files or non-compiling JSPs).
In this context, it might be helpful that your one-click deploy cycle also generates the appropriate project documentation. Maven is well known for the project documentation it generates. Just use the maven site:generate goal to generate the documentation of the current project. The resulting web site should look somewhat similar to the screenshot shown below:
Developing Multiple Projects
As your project's complexity increases, it is very possible that it might split into several smaller projects. The result: project management time has been multiplied. Each individual small project needs management.
The solution is to use a consistent build mechanism across different projects and create a "master project" that will hold those different smaller projects. While this is easy to do with Maven (as it forces you to adopt its project layout), it requires some form of discipline for Ant developers. For the Ant side of house, there are two recommendations:
- Use naming conventions ("compile" to compile the project, "dist" to create a distribution)
- Use the new <import/> task from Ant 1.6: Create a common Ant script that will be imported in each subproject. (This looks a lot like the "template method" design pattern from GoF.)
Another more complex issue is that those projects need to be built in a given order, and that the failure of one project will trigger the failure of its dependent subprojects. Let's take an example, in which you work on:
- A library of utility classes called myutility.jar
- A number of EJBs, packaged in a jar called myejbs.jar, and which use the classes from myutility.jar
- A web archive, called myweb.war, which uses both myejb.jar and myutility.jar
- An EAR file called myear.ear that packages the 3 aforementioned libraries.
In this case, a failure in the build process of myutility.jar will trigger the failure of all projects. But a failure of myweb.war will only trigger the failure of the final myear.ear.
Managing such project dependencies can either be done manually (if there are just a few projects) or automatically (with the Maven Reactor).
Packaging a J2EE Project
In many J2EE projects there is a need to create an archive file — such as a WAR, JAR, or EAR — to deliver to the client.
If you have followed the solutions to the previous issues, you have two very different challenges:
- Creating an EAR is complicated, especially when multiple projects are involved. An EAR is just a project that holds several WARs and JARs.
- Creating the WARs and JARs files are easy with Maven or Ant, but how do you manage the various deployment descriptors?
This is where an IDE such as Oracle JDeveloper is useful. However, if you do not wish to be dependant on an IDE, XDoclet, a code generation tool, can be run from within Ant and Maven to generate the aforementioned deployment descriptors.
I now leave you with a short tutorial to get you started with Maven and Oracle JDeveloper. Happy Building!
Managing Code Tutorial
Now, let's get started with Maven and create a ready-to-use Struts-based project.
Starting the Project
Maven can be downloaded from http://maven.apache.org/. The installation is pretty straightforward and fully documented at http://maven.apache.org/start/install.html.
Maven comes with an extensive list of plug-ins, which will be installed automatically from the Internet. (See the "Maven project repository" section.)
The Maven genapp plug in
The Maven genapp plug-in will help start quickly a Struts-based application. Run maven genapp and use the "struts" project template, as in the following screen shot:
You have now a working Struts-based web application. To create your project's WAR file, just type "maven war." This project has a simple POM (project.xml) file that you can edit according to your needs.
The Maven JDeveloper Plug in Use the Maven JDeveloper plug-in to import the project into Oracle JDeveloper. As explained in the plug-in's documentation, a few properties need to be set:
- Create a "build.properties" file in your home directory.
- Set up the properties required by the documentation
As an example, here is a screenshot of my own build.properties:
You can run the "maven jdeveloper" goal as many times as you want; it will update your Oracle JDeveloper configuration from Maven's project.xml file.
For example, it will automatically configure JDeveloper's libraries.
Running Maven inside JDeveloper It can be useful to run Maven from inside Oracle JDeveloper so that running Maven does not require launching a new console window. The screenshots below depict the configuration of the "maven dist" goal to a new button in Oracle JDeveloper. You would begin the process by choosing External Tools in the Tools menu and then selecting Add.
 |
| Step 1 of 4: selecting the Maven executable (the "dist" goal is chosen) |
 |
| Step 2 of 4: selecting how the Maven shortcut will be displayed |
 |
| Step 3 of 4:Specifying where the shortcut will appear in JDeveloper |
 |
| Step 4 of 4: Choosing when the shortcut will be available |
You can now run Maven from within Oracle JDeveloper, as in the screenshot below:
The Maven Console If you prefer using a console next to Oracle JDeveloper, using the Maven console plug-in is highly recommended. It will start Maven once, and will wait for instructions. As a result, running a goal is much quicker (compared to Ant).
Summary
Creating a new J2EE project is a very rich experience. The whole build cycle needs to be mastered, from managing the source files to deploying the packaged application. Thankfully, a rich set of tools is available to help the project manager succeed.
Maven is a powerful build tool that integrates well with Oracle JDeveloper. It is quite easy to set up, and thanks to its pre-configured plug-ins, Maven will provide an enormous gain of time over comparable solutions (like Ant). For less experienced developers and team leaders, Maven will have the added benefit of encouraging them to follow a number of best practices. Last but not least, using Maven guarantees the constant availability of a comprehensive project documentation, which so many enterprise projects lack.
Julien Dubois is a J2EE expert living in Paris, France. He can be found on the internet at http://www.julien-dubois.com.
[Back to J2EE Series Home Page]
| 
Bookmark
