Maven2 Log4J and JMX dependencies

Aarg!  What a nightmare.  I finally — fine, call me stupid — figured out where to/how to get the JMX dependencies for Log4J.
I am using Commons Logging, which in turn, likes to use Log4J.  So, I added this to my Maven project file (pom.xml):
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.15</version>
</dependency>

However, log4j has a dependency on jmx, which maven dutifully brings to my attention.

And this is where it gets interesting, the Maven repositories all have a pom for these but NOT the jar’s.
It turns out you need to download the jars from Sun’s Download site (which you have to register for).  (To navigate there, go to http://www.sun.com/download, then search the download center for JMX, then select the Java Management Extensions Download Information, then select the JMX 1.2.1 Reference Implementation,then select the JMX RI 1.2.1 download.  Whew!)

After downloading, you need to rename the jars from jmx*.jar to jmx*-1.2.1.jar.  Then you can register them with Maven (I use Artifactory, which made this a lot easier.)  Be sure to change the GroupId as follows:
com.sun.jdmk:jmxtools
com.sun.jmx:jmxri

With the jars in the repository, the JMX dependencies now resolve properly.

Fit Testing 101

Well, I finally got the Fitnesse server running and configured my first tests.  (Their site Fitnesse.org is down, but the Fitnesse jar’s were available here, and the zip was available on sourceforge.)  I run on Windows Vista, use Eclipse Europa as my IDE and Maven2 for the builds, so it was a bit of an ordeal to configure. Here’s what I ended up with.
My dev project is in standard Maven folders:
trunk>src>main>java>[package]>*.java
trunk>src>test>java>[package]>*Test.java
so I added:
trunk>src>test>fitnesse>[package]>fitnesse>fixtures>tests>FitTest*.java
(I’m quite sure that’s a naming violation of some sort, but it works for now. I can refactor it later when I find out what it should have been called.)

In my Eclipse project, I created this java class:
public class FitTestBasicTest extends ColumnFixture {
  public double quantity, price;
  public double extendedprice() {
    return quantity * price;
  }
}

I had to change the Maven pom to include the new test\fitnesse folder. So I used the build-helper-maven-plugin
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>add-test-source</id>
      <phase>generate-sources</phase>
      <goals>
        <goal>add-test-source</goal>
      </goals>
      <configuration>
        <sources>
          <source>/src/test/fitnesse</source>
        </sources>
      </configuration>
    </execution>
  </executions>
</plugin>

Now, whenever I run mvn test, it will compile the Fit tests as well as the JUnit tests.

Meanwhile, I unzipped the Fitnesse server and edited the run.bat file so that Fitnesse uses port 8083 instead of 80 because I already have a TON of web servers running on my dev box.  I just changed the java line to include the port parameter, like this:
java -cp fitnesse.jar fitnesse.FitNesse -p 8083 %1 %2 %3 %4 %5

So, with the Fitnesse Wiki running, I connected to http://localhost:8083/.
Following the Fitnesse model in their Acceptance Tests, I created a MyTests.SuiteAcceptanceTests page. It took a lot of fiddling to figure out what the Classpaths should be and how to get Fitnesse to find the test Fixture itself, but this works:
!2 ''!-My-! Acceptance Tests Suites''
|^SuiteTests|''Test Various Acceptance Scenarios.''|
----
!2 ''Classpaths''
!path C:\workspace\trunk\target\test-classes\
!path C:\workspace\trunk\target\classes\
----
!2 ''Fixtures''
!fixture com.myapp.fitnesse.fixtures.firsttests.FitTestBasicTest

Naming the fixture in the Suite’s page allows the -Insert Fixture Table – combo at the bottom of the page editor to insert a table from the class definition in the test fixture.  I also created a MyTests.SuiteAcceptanceTests.SuiteTests.SetUp page to handle the namespace import:
!|Import|
|com.myapp.fitnesse.fixtures.firsttests|

Lastly, I created the MyTests.SuiteAcceptanceTests.SuiteTests. MyFirstTest page.
I selected the Insert Fixture Table combo and picked the FitTestBasicTest class. Fitnesse inserted the table so I added some values. It turned out I needed to delete the line from the table that shows the types.
!|FitTestBasicTest|
|quantity|price|extendedprice()|
|10 |20 |200 |

So, the code compiles, the unit tests run and pass, the fit tests run and pass. Now, to mavenize the whole process again and get the maven fitness plugin working so the tests are run automatically.

Setting up Eclipse for Testing

So I started trying to figure out how to do Unit testing in Eclipse.
Eclipse defaults to JUnit 3 tests, but I want to use JUnit 4 tests. But the Eclipse JUnit 4 plugin is version 4.3 and I want to use 4.4. Then there is the difference between Assert.True and Assert.That, the latter requiring (or at least benefiting from) Hamcrest.
So I finally removed the Eclipse Junit 4.3 library from my BuildPath and added the junit-4.4.jar and hamcrest-all-1.1.jar instead.
In the process, I came across this Unit Testing in Eclipse page, which includes the fit.jar. Well, that launched me into another search as I tried to figure out how to run Fit tests in Eclipse. It turns out that Chengyao Deng wrote his masters thesis on this topic. That led me to the FitClipse Installation Instructions.
Well, my testing configuration wouldn’t be complete without jMock, so I found the jmocklipse site. No code present, just a good idea in Google’s suite of good ideas. Oh well, I can include the external jar manually.
So, now I have Junit, Hamcrest, Fit and jMock all set up and ready to test.
Now…if only I had something to test…

Further Reading:
FIT and Eclipse
Using JUnit with Eclipse IDE

Back from the Spring Experience 2007

After spending 3 gorgeous days on the beach in Hollywood, FL (think Ft. Lauderdale), I have returned to a much cooler Charlotte than the one I left. No more record highs for us.

The Spring Experience 2007 was a great conference. As usual, some of the presenters demonstrated why nerds get a bad rep (can you spell b-o-r-i-n-g), others were excellent. In both cases, the content was great, its just the presentation style that lacks a certain je ne sais quoi. And that reminds me, where was the book store? Almost every single presenter has authored one or more tomes for our consumption, and yet here I sit on Monday morning with nary a one for my troubles. We did get a NFJS book as a consolation, but a book store in the lobby would have seriously helped my chiropractor’s Christmas budget. (As it was I had to unload 20 pounds of paper from my suitcase in order to not exceed the 50# per bag weight limit. Grrr.)

If Spring started its life as a Dependency Injection container, it has certainly come a long way. There are many new layers to this onion and it promises to keep growing. Rod Johnson, founder of Spring and now CEO of SpringSource (formerly Interface21), has brought many key players in the open source community together to create the formal infrastructure necessary to support Spring longer term.

I look forward to implementing the Spring Framework, Spring Security, Spring Web Services, Spring Web Flow, Spring Batch, Spring Integration, Spring Dynamic Modules, Spring, Spring, Spring, Spring, Spring, Spring Batch and Spring. :)

Follow

Get every new post delivered to your Inbox.