Setup internal maven repository

I have configured a maven proxy for my company so that each developer is not going out and downloading artifacts. This also allows us to have a single company wide repository for our artifacts. The setup steps are not the complicated, but I did run into several issues when I first setup the proxy. Hopefully, this simplifies the process.

1. Download maven-proxy from codehaus.
2. Follow the instructions to setup a manual instance.
3. Modify the default properties file in the maven-proxy directory.. See the attached maven-proxy.doc for a sample. Save this file and change the extension to .properties. You will need to change the name and prefix of your proxy if you don’t like MyRepo.

   maven-proxy properties file

4. Create a startProxy.bat file instead of manually typing “java -jar….” every time.
   My batch file contains the following line:

   
java -jar maven-proxy-standalone-0.2-app.jar maven-proxy.properties

5. Configure the .bat file from the previous step to startup when the machine starts. I put the bat file in my Startup folder.
6. Run the startProxy.bat file and verify startup
7. Configure your dev machine to work with the proxy by editing your settings.xml. See the attached ClientRepoSettings.doc document for a sample of configuring your client machine.

   Maven settings.xml file

8. Clean out your local .m2 repository
9. Clean and compile your project to verify that all artifacts are being pulled down from the proxy. You can check the proxy window output to verify that the artifacts are going through the proxy.

Using Cobertura with Maven

Configuring Cobertura is quite easy with Maven. You need to add two entries to your pom.xml.

First, add the following to your build section:

1.       <plugin>

2.         <groupId>org.codehaus.mojo</groupId>

3.         <artifactId>cobertura-maven-plugin</artifactId>

4.         <executions>

5.           <execution>

6.             <goals>

7.               <goal>clean</goal>

8.               <goal>check</goal>

9.             </goals>

10.           </execution>

11.         </executions>

12.         <configuration>

13.           <instrumentation>

14.             <includes>

15.               <include>**/*.class</include>

16.             </includes>

17.             <excludes>

18.               <exclude>**/*Test.class</exclude>

19.               <exclude>**/Base*.class</exclude>

20.               <exclude>**/*Filter.class</exclude>

21.               <exclude>**/NTLM*.class</exclude>

22.             </excludes>

23.           </instrumentation>

24.           <check>

25.             <totalLineRate>70</totalLineRate>

26.             <totalBranchRate>70</totalBranchRate>

27.           </check>

28.         </configuration>

29.       </plugin>

The plugin allows you to setup your coverage thresholds and any include/excludes. In this example, I’m excluding all of my test cases, and anything related to base abstract classes. I’m also excluding NTLM code because that is not currently used in the project and there are no test cases for the code.

Second, setup a reporting plugin so Cobertura will generate its reports when the Maven site is generated:

      <plugin>

        <groupId>org.codehaus.mojo</groupId>

        <artifactId>cobertura-maven-plugin</artifactId>

      </plugin>

Configuring Maven to utilize a different resource for each build environment

One of the most frustrating things I have experienced with Maven is how to use different config files for each build environment. For example, I usually end up with some differences between dev, test, and prod environments. In Ant, I could simply create a file for each environment and then copy the file based on a command line arg.

Maven doesn’t have a facility for this, or at least I couldn’t find a good way to do this. There are various posts about how to do something similar, but I never found a great way to handle it.

My solution is to use Ant since that has always worked. All you need to do is configure the Antrun plugin and then write Ant tasks inside of your pom. It’s actually quite slick once you do it the first time. This is also a good tip to use when Maven doesn’t have a plugin or functionality that you can already do in Ant.

1. <plugin>

2.      <artifactId>maven-antrun-plugin</artifactId>

3.      <executions>

4.         <execution>

5.            <id>CopyResources</id>

6.            <phase>compile</phase>

7.            <configuration>

8.               <tasks>

9.                  <echo message="### START - copy files based on server.name param ###"/>

10.                  <echo message="    server.name=${server.name}"/>

11.                  <copy file="src/main/resources/applicationContext-ds.${server.name}"

12.                                         tofile="${project.build.outputDirectory}/applicationContext-ds.xml" overwrite="true"/>

13.                  <echo message="### END   - copy files based on server.name param ###"/>

14.              </tasks>

15.            </configuration>

16.            <goals>

17.               <goal>run</goal>

18.            </goals>

19.          </execution>

20.      </executions>

21. </plugin>

With this config, you always have to have a -Dserver.name=xxx argument when you run mvn. If you don't, you will get an error about not being able to copy file "applicationContext-ds-${server.name}" because Maven doesn't have a variable to substitue in the server.name place.

This simple trick simply copies my environment specific Spring datasource config to the applicationContext-ds.xml file. Each build will end up with a single application-ds.xml file that is configured to the environment.

Configuring BEA WebLogic 8.1 with Hibernate 3.x

Both of these apps use a version of ANTLR. Hibernate uses 2.7.6rc1 while WebLogic use 2.7.1. In order for Hibernate 3 to run under WebLogic 8.1, a classpath change is required.

The ANTLR code for WebLogic is part of the server\lib\weblogic.jar so it’s impossible to replace just the ANTLR jar file. Instead you have to setup a PRE_CLASSPATH that puts the Hibernate jar in the classpath before the weblogic.jar.

1. Edit startWebLogic.cmd located in bea\user_projects\domains\mydomains. Change the line for the PRE_CLASSPATH to read:


set PRE_CLASSPATH=%WL_HOME%\common\lib\antlr-2.7.6rc1.jar


2. Copy the ANTLR jar from the Hibernate distro to WL_HOME\common\lib. For me, WL_HOME is C:\bea\weblogic81, but you can find your setting in the startWebLogic.cmd file.

Now when WebLogic starts an application that uses Hibernate3, you should not get any errors.

Maven site-deploy

Maven can deploy your site artifacts to a remote location, but of course Windows had to throw a wrench into my plans. Under Windows, I could not get Maven to reference a remote location by hostname or IP.

My workaround was to create a mapped drive for Y. My pom excerpt to work with the mapped drive follows:

website
file:///y|’artifactId’

Replace the ‘artifactId’ with the name of your project. This will put the site for each project into it’s own directory.

Installing jars into Maven

I can never remember the syntax for installing files into a local or remote Maven repo so here is my cheat sheet.

Installing into the local repo:

mvn install:install-file -DgroupId=xxx -DartifactId=xxx -Dversion=xxx -Dpackaging=jar -Dfile="
c:\blah\blah\blah.jar"


change the xxx values to the appropriate values for your jar

Installing into the remote repo:

mvn deploy:deploy-file -DgroupId=xxx -DartifactId=xxx -Dversion=xxx -Dpackaging=jar -Dfile="c:\blah\blah\blah" -Drepository=myRepo -Durl="file:///x|local-repo"


Notes:

• myRepo is the name of my remote repository that I have configured in my settings.xml
• The url is a mapped drive to my remote repository. I tried various configuration using the hostname and a shared drive but nothing worked. For Windows, I created a mapped drive for X: and then my repo is under the “local-repo” directory on X:

Set the JVM for Tomcat 5.x to a value different from JAVA_HOME

While most of my development is done in Java 1.4, I wanted to play around with 1.5 a while back. In order to run Tomcat with 1.5 but keeping JAVA_HOME pointing to 1.4, I created a simple batch file to setup the JAVA_HOME and CATALINE_HOME directories. There is a separate Tomcat installation so that I can have Java 1.5 features and jars installed there.


echo Setting values for Java5
set JAVA_HOME=d:\dev\jdk1.5.0_05
set CATALINA_HOME=d:\dev\tomcat50Java5
echo Set values
echo Starting server
startup.bat