This is what you can do to fix it. First, we need to convert this project into Eclipse WTP web project.

This is .project file before modification

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>web</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.maven.ide.eclipse.maven2Builder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.maven.ide.eclipse.maven2Nature</nature>
	</natures>
</projectDescription>

We need to add a new builder and a new nature to the project. You will need to insert this XML code into this file.

This will go under build spec section:

	<buildCommand>
		<name>org.eclipse.wst.common.project.facet.core.builder</name>
		<arguments>
		</arguments>
	</buildCommand>

and this will go under natures:

	<nature>org.eclipse.wst.common.project.facet.core.nature</nature>

This is .project file after modification:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>web</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.maven.ide.eclipse.maven2Builder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.wst.common.project.facet.core.builder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.maven.ide.eclipse.maven2Nature</nature>
		<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
	</natures>
</projectDescription>

Now you need to go to project properties and select appropriate facets. To do that you need to right click on the project name and select Properties. On project Properties dialog you will need to select Project Facets.

On that screen you will need to select Dynamic Web Module, and appropriate version of Java for this module. For example if you select Dynamic Web Module version 2.5 you will need to have Java 5 or higher selected too.

Once you selected these facets and saved project project properties Eclipse will add new folder to your project called WebContent. This is the folder where Eclipse will store all the web files such as web.xml and JSPs.

Now you have a web project that will be recognized by Eclipse and you can add this project to your server.

The problem with this is that Maven does not know anything about this WebContent folder and won’t be able to build you project. You have two options: you can update the POM file to change the location of webapp folder, or you can update project settings to replace WebContent with /src/main/webapp.

This is what you need to do: open up org.eclipse.wst.common.component file under .settings folder. It would look like this:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="web">
        <wb-resource deploy-path="/" source-path="/WebContent"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
        <property name="context-root" value="web"/>
        <property name="java-output-path" value="/web/target/classes"/>
    </wb-module>
</project-modules>

Replace /WebContent with /src/main/webapp and save the file.

This is what updated file would look like:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="web">
        <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
        <property name="context-root" value="web"/>
        <property name="java-output-path" value="/web/target/classes"/>
    </wb-module>
</project-modules>

Now you can delete WebContent folder and your project is fully configured with web support and can be debugged inside Eclipse and build by Maven.

This is how you can accomplish this. You need to configure Javadoc plug-in in your POM file

    <reporting>
    	<plugins>
		    <plugin>
		    	<groupId>org.apache.maven.plugins</groupId>
		    	<artifactId>maven-javadoc-plugin</artifactId>
		    	<!-- Add this if you use Java 5 -->
		    	<configuration>
		    		<javadocVersion>1.5</javadocVersion>
		    	</configuration>
		    </plugin>
    	</plugins>
    </reporting>
    <build>
    	<plugins>
    		<plugin>
    			<groupId>org.apache.maven.plugins</groupId>
    			<artifactId>maven-javadoc-plugin</artifactId>
    			<executions>
    				<execution>
    					<id>attach-javadocs</id>
    					<goals>
    						<goal>jar</goal>
    					</goals>
    				</execution>
    			</executions>
    		</plugin>
	    	<!-- Add this if you use Java 5 -->
    		<plugin>
    			<groupId>org.apache.maven.plugins</groupId>
    			<artifactId>maven-compiler-plugin</artifactId>
    			<configuration>
    				<verbose>true</verbose>
    				<fork>true</fork>
    				<compilerVersion>1.5</compilerVersion>
    				<source>1.5</source>
    				<target>1.5</target>
    			</configuration>
    		</plugin>
    	</plugins>
    </build>

mvn clean compile package -DdownloadSources=true

While this is perfectly fine for the new applications for some existing projects this file structure might be inappropriate. Unfortunately some times you cannot change the existing file structure as you pleased. For example, if you use PVCS as your source control system, then you don’t want to change the existing file structure because it is very difficult to update the source repository.

Another issue that you might have is integration with development tools such as WSAD or Eclipse Web Tools. By default they use different file structure for web projects and unless you want to take a way from people the ability to use debugger you better follow the same file structure as WSAD suggests.

To implement this we will have to modify our POM file and configure maven-war-plugin to tell it where to find web resources. You need to specify the path to the folder that contains the web content. This is how you configure the war plug-in

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 

http://maven.apache.org/maven-v4_0_0.xsd">

	<modelVersion>4.0.0</modelVersion>
	<groupId>com.garbuz.maven</groupId>
	<artifactId>test-web-project</artifactId>
	<packaging>war</packaging>
	<version>1.0</version>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-war-plugin</artifactId>
				<version>2.0</version>
				<configuration>
					<warSourceDirectory>WebContent</warSourceDirectory>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

This is how you can accomplish this. You need to configure source plug-in in your POM file

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-source-plugin</artifactId>
			<executions>
				<execution>
					<goals>
						<goal>jar</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

If you execute “deploy” goal now you will see that in your repository there will be another JAR file – yourproject-1.0-sources.jar.

You may also need to deploy your automated tests. This will help you to avoid writing duplicate code and eventually minimize the maintenance cost. If you want to deploy your test classes with your project you need to configure jar plug-in:

	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-source-plugin</artifactId>
			<executions>
				<execution>
					<goals>
						<goal>jar</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-jar-plugin</artifactId>
			<executions>
				<execution>
					<goals>
						<goal>test-jar</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

And if you wish to include test sources then your POM file will look like this:

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-source-plugin</artifactId>
			<executions>
				<execution>
					<goals>
						<goal>jar</goal>
						<goal>test-jar</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-jar-plugin</artifactId>
			<executions>
				<execution>
					<goals>
						<goal>test-jar</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

You can also put this into your super POM file and make all your project POM files extend this one. Then all your projects will deploy sources and tests by default.

This is that you can do to fix the problem.

1. Create a directory and place your selenium-driver.jar in this directory.
2. Copy your selenium-server.jar file in the newly created directory and go into this directory.
3. Unzip the jar files contents here.
4. First find all the *.rdf files – you should see 5 of them:
   • ./customProfileDirCUSTFF/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
   • ./customProfileDirCUSTFF/extensions/readystate@openqa.org/install.rdf
   • ./customProfileDirCUSTFFCHROME/extensions/{503A0CD4-EDC8-489b-853B-19E0BAA8F0A4}/install.rdf
   • ./customProfileDirCUSTFFCHROME/extensions/{538F0036-F358-4f84-A764-89FB437166B4}/install.rdf
   • ./customProfileDirCUSTFFCHROME/extensions/readystate@openqa.org/install.rdf
5. In each of these files you will see hardcoded version like this: 3.5.* Change them to 3.6.*
6. All the files are now patched. Zip up the extracted files into a new JAR file selenium-server-new.jar

Now you should all set to use this patched version of selenium. You can delete your old selenium-server.jar file if you’d like.

Fortunately, you can use your own custom profile and run your Selenium functional tests using this profile. In that case you can accept all of the certificates once and Firefox will never prompt you to accept them again. This is how you do this:

• Navigate to the directory that contains your Firefox profile. If you use Windows then this directory is something like this C:\Documents and Settings\[your login name]\Application Data\Mozilla\Firefox\Profiles
• In this directory you will see a subdirectory with Firefox profile in it. It would look something like this zv7rrcv8.default.
• Copy this entire directory and save it under selenium.default name.
• Then navigate to this folder and open up prefs.js file in text editor. Find the line that says:
  user_pref("browser.startup.page", 0);
  and comment it out like this
  //user_pref("browser.startup.page", 0);
• Then open up the bat file that you use to start selenium server.

Use this command to start Selenium server:

java -jar ./selenium-server-0.9.2.jar -firefoxProfileTemplate "C:\Documents and Settings\[your login name]\Application Data\Mozilla\Firefox\Profiles\selenium.default"

Now you can run your functional test against Selenium server using your own Firefox profile and not worry about SSL certificates, and other things that are specific to your network.

Unfortunately, being an open-source project Cobertura seriously lacks documentation, especially regarding how to configure Maven 2 plug-in. One of the most common problems with Cobertura is when generated report shows 100% test coverage while in reality many of the classes do not have tests.

The reason for this is that Cobertura did not perform code instrumentation during the site generation phase. As the result the coverage information is incorrect.

This is the example of how you can configure this report so that it would reflect real test coverage.

	<build>
		<plugins>

			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>cobertura-maven-plugin</artifactId>
				<executions>
					<execution>
						<id>site</id>
						<phase>pre-site</phase>

						<goals>
							<goal>clean</goal>
						</goals>
					</execution>
					<execution>
						<id>instrument</id>
						<phase>site</phase>

						<goals>
							<goal>instrument</goal>
							<goal>cobertura</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
					<instrumentation>

						<excludes>
							<exclude>com/test/ClassToIgnore.class</exclude>
							<exclude>com/test/**/*Test.class</exclude>
							<exclude>com/test2/**/*.class</exclude>
						</excludes>
					</instrumentation>
				</configuration>

			</plugin>
		</plugins>
	</build>

And then we need to add this code to reporting section of our POM file

	<reporting>
		<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>cobertura-maven-plugin</artifactId>

			</plugin>
		</plugins>
	</reporting>

Have you ever seen how the car engines are being diagnosed nowadays? There are special computers at the car repair facilities that can be hooked up right to your car. Inside the engine there are several embedded sensors that can communicate with this computer. They transmit information about the engine’s conditions to the computer and it tells you exactly what is going on. Isn’t it quite amazing?

As a software developer I always wanted to have this special computer that could tell me instantly why my code is not doing what it’s supposed to do. Unfortunately, there is no such computer in a real world. However, there is something else that can do pretty much the same job. It is called test driven development.
How can you, as a programmer, make sure that your code is functional and meets the client’s expectations? What are the ways to verify that nothing has changed in the system’s behavior since the last server upgrade? Can you make a certain change without breaking the entire system? To answer these questions we have several options.

Option number one is to remain ignorant and continue the development process hoping that at the end things will just work. While many people use this naive approach, it is not hard to imagine what can happen at the end. Usually, this would result in a failed project and potentially a request for the HR department to hire a new project manager to replace the one who led the project.

The second option would be to hire a tester – someone whose job responsibility would be to run your code and make sure it behaves according to the specification. While this approach sounds easy enough, it has one serious problem: you can’t start testing until your code it written completely, or at least you have enough of it so you can execute it. But, what if you made a mistake along the way and your code simply doesn’t run? How can you, as a programmer, quickly find out where the problem is? Using this approach, it is going to be very hard or sometimes even impossible to identify the source of the problem and resolve it in a short period of time. Not only is it going to be very difficult, it is also going to be very time consuming and expensive. Not to mention that once you found the error, there is no guarantee that the code will run. You simply might have another error similar to the one you just fixed somewhere else in the code and you will have to repeat the entire debugging processes over and over, again and again, until all the problems are fixed.

Fortunately for us there is another way. It is called test driven development. The idea behind this approach is to develop a suite of automated tests that can test your code on a regular basis and provide you with valuable feedback regarding the conditions of the program you’re writing.

This is how it works in general. First, you develop your tests and only then you write your code. By the time you start writing your main system code you already have a unique custom-built tool that can almost instantly diagnose your system and tell you if there are any problems. When you get to the point where you need to finish your project, your code will be intensively tested from inside out using variety of test scenarios and many of the potential problems will be already identified and removed. And even if a new problem occurs, it is going to be relatively easy to narrow it down and eliminate the source of the problem in a short period of time. Sounds good, doesn’t it?

Well, before we go any further we need to define what the unit test is. This is the definition given to us by Wikipedia – a free on-line encyclopedia:

In computer programming, a unit test is a procedure used to verify that a particular module of source code is working properly. The idea about unit tests is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed.

Personally, I am not completely satisfied with this definition, that’s why I came up with my own:

A unit test is a software module that verifies the results of a single operation or a unit of functionality by emulating a user’s request and comparing the generated output with predefined data.

The concept of unit testing is based on the same idea as using the embedded sensors to diagnose your car engine. Each unit test acts similar to those sensors – it verifies the correct execution of one single block of code and reports you whether it worked according to the expectations or not. The more sensors you have inside your code the better it is going to be in the future. They execute your program and compare the generated output with the previously defined data. If they match then test passes, otherwise the test fails and a message indicating the test failure will be displayed. That doesn’t look like something really difficult, right? In fact, making sure that your code passes the test is usually much easier than trying to find why your program doesn’t work.

Do you remember the old days when you had to take your car to the mechanics and they would spend hours trying to investigate why your car started to consume all this extra fuel? They would always be glad to do all this work for you, because at the end they would charge you for every minute they spent working on your car. The worst part of it was that once they told you they fixed, what they thought was broken, there was really no guarantee that they really fixed the problem instead of introducing a new one. And the next time you would come to them again and spend your time and money trying to get your car back in the shape.

Those of you who have had experience managing or coordinating the software projects will definitely see some similarities. How often do we find ourselves in the situation when we need to make a change to the code and simply can’t do this because we are not sure if this change is going to break some existing functionality? How often do we hear from software developers that it will take ten minutes to implement the required changes and another three or four hours (or even days) to complete the full system test? To make matters worse, imagine the situation when one of the core developers just quit the job. How can a new person, who was recently hired, tell if the change that is about to be implemented is going to break something else?

The answer to all this questions is – use automated test driven development process. Do not try to save money on testing your products. In the end, poorly written code represents a serious liability to the clients. It is much like manufacturing untested cars. You would not want to drive a car that never went through a crash test, right? If something goes badly, you might find yourself working on your resume a lot sooner that you had expected.

However, despite the obvious advantages and benefits that test driven development can provide for us, many people still remain suspicious. One of the most often used arguments against test driven development is: “I don’t have this extra time required to write tests”. Well, it is really easy to beat. All you need to do is ask them – how much time do you have to debug your code? Would you rather spend time and energy on debugging your code instead of writing the unit test? If the answer is yes then this person should probably consider doing something else other than software development.

Another very hard thing to do is to convince your management to allocate additional time and recourses to develop unit tests. This one is a little bit more difficult. Unfortunately, managers and especially those who don’t have any technical background often don’t see the benefits of writing the unit tests because, in their eyes, it is just another activity that programmers like to do. The best way to convince the management in this situation is to demonstrate in practice, using a real life example, how the test driven development can save time and money and at the same time improve the quality of the product. It is good to start with a small project and use it as a sand box to sharpen the required skills before going into the deep waters and starting to work on a large project. It is going to be a lot easier to receive managerial approval to try something new while developing a small module to enhance the exiting system than on a huge enterprise wide mission critical project.

There are number of tools that can help developers to utilize test driven development. Probably, the most well known is JUnit – a framework written in Java programming language. JUnit provides software developers with a set of predefined objects that can be extended for their purposes. JUnit is an open source project and available for download from its own web site: www.junit.org.

Without any doubts, one of the biggest advantages of JUnit is its tight integration with modern development tools. Almost every existing integrated development environment (IDE) for Java including Intellij IDEA, Eclipse, NetBeans, and JBuilder has a built-in JUnit test runner. Another significant advantage that JUnit gives to developers is the ability to run unit tests while building the projects using different build tools such as Ant, Maven, and Cruise Control. For those who can’t or simply don’t want to use Java there is a .NET port of JUnit framework called NUnit.

There are also many other tools and frameworks that can help developers to design and develop the unit tests for their projects. More information on this subject is available from www.junit.org.