Showing posts with label maven. Show all posts
Showing posts with label maven. Show all posts

Disabling test under JUnit 4.4

Recently I had to disable a unit test in our test system. We use Maven as our build tool and JUnit 4.4 for unit testing. I had a few options,

  1. Exclude that particular class from tests under surefire plugins configuration in my pom.xml
  2. Remove @Test annotation from test method in the test class. Which fails as it finds a Test class but does not find any test methods
  3. Rename the class from say MyTest to something that does not end with "Test" say "Tezt"
I remembered that in TestNG you can just disable a test by saying @Test (enable = false) and I was desperately trying to find how to do this in JUnit 4.4. But to my dissappointment Test annotation only allows a couple of attributes, timeout and expected which did not do what I want.

After looking at the JUnit javadocs, I stumbled upon an annotation @Ignore it is indeed an annotation to be used if you want to skip the test.

So if you want to disable your test case in JUnit 4.4 just annotate your test methond with @Ignore @Test annotations.

What it also did was that Maven started reposting one test as being "Skipped" which is nicer as it keeps reminding you that you need to look after the test that you have disabled.

Animal Sniffer Maven Plugin

While looking at the Maven plugins at Codehaus, I just stumbled upon a maven plugin named Animal Sniffer. This plugin could be a great tool for people working on frameworks where API's are published to the user. There is always a problem of API loosing the compatibility across versions (for eg. making some method final looses backward compatibility). These kind of problems are very very difficult to trap.

I wanted to evaluate this plugin for instrumenting our internal API against which following versions can check compatibility. Firstly I am not sure if Animal Sniffer can be used in this way but I believe it could be.

I tried to play with the plugin a little where I figured out that vresion 1.5-SNAPSHOT cannot be downloaded from the Codehaus snapshot repository and older versions 1.4, 1.3 encounter an NPE when I run animal-sniffer:build goal.

Does anyone have experience with Animal Sniffer?

Log4j 1.2.15 with Maven

I had a problem with Log4j version 1.2.15 where after adding a Log4j dependency, maven would try to download dependencies like java mail, jmx etc. The download never seem to finish as it is from some external repository. I am not sure if it was a temporary problem. I figured the problem was version 1.2.15 when I looked at the pom of that version and I could see some dependencies with specific repository.

Migrating to version 1.2.14 seem to fix this problem.

Runnable jar using maven assembly plugin

I faced a nagging problem of not able to create a runnable jar using Maven assembly plugin. I had a couple of dependencies which were required at runtime. I used the jar-with-dependecies assembly to achieve this. But my Main-Class attribute from the MANIFEST.MF was lost every time.

The solution to this problem is archive configuration under assembly plugin as described here

Environmental variables, Maven and Eclipse

If you use m2eclipse for building Maven projects in Eclipse, there are some issues while building projects having variables defined which refer Environmental Variables.

<properties>
<appserver.home>${env.APPSERVER_HOME}</appserver.home>
</properties>


Some of our developers came out with an idea of replacing the value locally to point to the directory on their machine like


<properties>
<appserver.home>/home/developer/software/appserver/</appserver.home>
</properties>


This lead to numerous incidents where developers checked in the hard coded path for this variable in our code repository, which lead to failed builds on our Hudson.

A better way to manage this is using profiles. You can create a profile in your settings.xml which resides under .m2 directory in your home directory on Linux (not sure where on Windows). Example profile configuration is as follows,


<profiles>
<profile>
<id>eclipse</id>
<properties>
<appserver.home>/home/developer/software/appserver</appserver.home>
</properties>
</profile>
</profiles>


Now you have a profile named eclipse which points to the absolute path for the varialbe appserver.home.

Now checking out / importing a maven project you can specify profile as eclipse. Or in an already checked out Maven project (note that the project needs to be checked out as Maven Project. Same thing will not work on simple java projects even if they use maven), go to project properties -> Maven and set the profile to "eclipse" (the same as id parameter in your settings.xml)

Now what this does is when you make build from eclipse, it uses the profile "eclipse" and resolves the variable to the right value. Advantage of this approach is that you do not need to change pom.xml of the project so it avoids the problem of checking in the hard coded values by mistake.