sh1nj1 / fitnesse-launcher-maven-plugin Goto Github PK

This issue may be relevant, particular the MavenCompatibilityHelper. 
https://github.com/TimMoore/mojo-executor/issues/13

What steps will reproduce the problem?
1. Specify a suite to be executed in <configuration> section of POM (e.g. 
<suite>FirstSuite</suite>
2. Try to override this setting with specifying command line parameter, e.g. 
-Dfitnesse.suite=SecondSuite
3. Observe that FirstSuite is executed instead of SecondSuite

What is the expected output? What do you see instead?

Expected output is for command line settings to take precedence over whatever 
is defined in POM

What version of the product are you using? On what operating system?

v.1.2.2 both Windows and Linux

Please provide any additional information below.

v.1.2.2

Currently there is no way of specifying more than one suite/test for execution 
in run-tests goal.

Is there a way to debug fitnesse tests in wiki mode ?

I'm pair-fitnessing with a business analyst, so we need to see the wiki page, 
and i would be glad to debug with my EDI instead of sysout.

In order to be able to override specific pages in the FitNesse wiki (e.g. the 
FrontPage), the unpacking of FitNesseRoot as part of the setup goal should not 
overwrite any existing resources.

The attached patch adds "overwrite=false" to the implementation of the 
unpacking as part of the SetUp mojo.

What steps will reproduce the problem?
1. Run fitnesse server on port 9123
2. Run a build with fitnesse-server-maven-plugin running fitnesse server on 
port 9123
3. Observe the build pass although fitnesse server cannot be started.

What is the expected output? What do you see instead?

Expected output should be for build to fail on every condition other than all 
fitnesse tests pass. So in this case if fitnesse server cannot be started the 
build should fail.

What version of the product are you using? On what operating system?

1.2.2 on Windows and Linux

Please provide any additional information below.

Excerpt from build log:
[13:51:29]:      [prm:prm-fitnesse-tests] Bind exception on port = 9123
[13:51:29]:      [prm:prm-fitnesse-tests] FitNesse cannot be started...
[13:51:29]:      [prm:prm-fitnesse-tests] Port 9123 is already in use.
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] 0 right, 0 wrong, 0 ignored, 0 
exceptions
[13:51:29]:      [prm:prm-fitnesse-tests] Use the -p <port#> command line argument 
to use a different port.
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] 
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] --- 
fitnesse-launcher-maven-plugin:1.2.2:tear-down (default) @ prm-fitnesse-tests 

---
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] 
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] --- 
maven-failsafe-plugin:2.12.3:verify (default) @ prm-fitnesse-tests ---
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] No tests to run.
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] 
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] --- 
fitnesse-launcher-maven-plugin:1.2.2:verify (default) @ prm-fitnesse-tests ---
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] 
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] --- 
maven-install-plugin:2.3.1:install (default-install) @ prm-fitnesse-tests ---
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] Installing 
D:\project\tcity\agentWork\apdtcityW8d_Windows\work\2b2173dbb4581847\prm-accepta
nce-tests\prm-fitnesse-tests\target\prm-fitnesse-tests-12.4.0-SNAPSHOT.jar to 
D:\project\tcity\agentWork\apdtcityW8d_Windows\.m2\repository\prm\prm-fitnesse-t
ests\12.4.0-SNAPSHOT\prm-fitnesse-tests-12.4.0-SNAPSHOT.jar
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] Installing 
D:\project\tcity\agentWork\apdtcityW8d_Windows\work\2b2173dbb4581847\prm-accepta
nce-tests\prm-fitnesse-tests\pom.xml to 
D:\project\tcity\agentWork\apdtcityW8d_Windows\.m2\repository\prm\prm-fitnesse-t
ests\12.4.0-SNAPSHOT\prm-fitnesse-tests-12.4.0-SNAPSHOT.pom
[13:51:29]:      [prm:prm-fitnesse-tests] [INFO] Installing 
D:\project\tcity\agentWork\apdtcityW8d_Windows\work\2b2173dbb4581847\prm-accepta
nce-tests\prm-fitnesse-tests\target\prm-fitnesse-tests-12.4.0-SNAPSHOT-sources.j
ar to 
D:\project\tcity\agentWork\apdtcityW8d_Windows\.m2\repository\prm\prm-fitnesse-t
ests\12.4.0-SNAPSHOT\prm-fitnesse-tests-12.4.0-SNAPSHOT-sources.jar
[13:51:30]:  [Step 2/2] [INFO] 
------------------------------------------------------------------------
[13:51:30]:  [Step 2/2] [INFO] Reactor Summary:
[13:51:30]:  [Step 2/2] [INFO] 
[13:51:30]:  [Step 2/2] [INFO] RM :: Acceptance Tests :: Database Tools 
.......... SUCCESS [10.886s]
[13:51:30]:  [Step 2/2] [INFO] RM :: Acceptance Tests :: Fitnesse Fixtures 
....... SUCCESS [12.667s]
[13:51:30]:  [Step 2/2] [INFO] RM :: Acceptance Tests :: Fitnesse Tests 
.......... SUCCESS [2:02.237s]
[13:51:30]:  [Step 2/2] [INFO] 
------------------------------------------------------------------------
[13:51:30]:  [Step 2/2] [INFO] BUILD SUCCESS
[13:51:30]:  [Step 2/2] [INFO] 
------------------------------------------------------------------------
[13:51:30]:  [Step 2/2] [INFO] Total time: 2:26.119s
[13:51:30]:  [Step 2/2] [INFO] Finished at: Mon Jul 08 13:51:30 CDT 2013
[13:51:30]:  [Step 2/2] [INFO] Final Memory: 53M/742M
[13:51:30]:  [Step 2/2] [INFO] 
------------------------------------------------------------------------
[13:51:30]:  [Step 2/2] Process exited with code 0

Implement the include / exclude tag filters on the suite so that in the pom, 
when you define a suite of tests to run, you could specify which children to 
include or to exclude based on some tags.

For instance, you might want to filter out some tests which are failing, and 
which you are investigating:

<configuration>
 <suite>MySuite</suite>
 <excludeTag>KnownIssues</excludeTag>
</configuration>

When <useProjectDependencies> is specified, the project dependencies for the 
specified scope(s) are programmatically resolved transitively, but on a 
one-by-one basis. That means that if two project dependencies have a common 
transitive dependency, it will be duplicated, even with conflicting versions.

The attached patch changes the resolution mechanism for dependencies to instead 
be resolved by the Plugin API (using the standard dependency resolution 
mechanism), which gives the expected behavior.

The actions performed in the setup goal (cleaning, expanding the fitnesse.jar 
and moving the FitNesseRoot folder into the workingDir folder) can take quite 
some time on startup. A proven practice from many code or resource generating 
plugins is to use a marker file to indicate that generation has taken place, to 
avoid unnecessary, repetetive re-generation. The marker file itself is 
typically removed together with the generated resources, e.g. as part of the 
"clean" lifecycle.

The attached patch adds a configuration property "fitnesse.markerFile" that, if 
set, provides the name of a marker file. If set and the marker file exists, the 
setup goal succeeds without actions. If set and the marker file doesn't exist, 
the ordinary setup actions are executed, and on successful completion the 
marker file is created for future reference.

Below is an example configuration:

      <plugin>
        <groupId>uk.co.javahelp.fitnesse</groupId>
        <artifactId>fitnesse-launcher-maven-plugin</artifactId>
        <configuration>
          <markerFile>${project.build.directory}/fitnesse-launcher-plugin-marker</markerFile>
          ...
        </configuration>
      </plugin>

Would be nice to be able to use all features of tags selection that is 
supported bij Fitnesse. Currently I don't see the option to use 
runTestsMatchingAllTags parameter.

See: http://fitnesse.org/FitNesse.UserGuide.TestSuites.TagsAndFilters


This feature is introduced since 20 -  12 - 2012:
http://fitnesse.996250.n3.nabble.com/ANNOUNCE-FitNesse-20121220-td2442.html

Since we use SymbolicLinks in our test page hierachy, and SymbolicLinks cannot 
be nested, we are not using the <createSymLink> option in 
fitnesse-launcher-maven-plugin. Instead, we use src/test/fitnesse as 
<workingDir>, and use .gitignore for everithing else than our own test page 
hierarchy.

In src/test/fitnesse, we also have a plugins.properties file (since we use the 
SlimTables plugin to specify a couple of custom Slim table types). This 
combination however doesn't work, since fitnesse-launcher-maven-plugin for some 
reason in the "clean" stage of the set-up goal explicitly removes 
plugin.properties from <workingDir>.

Is it really necessary to remove plugins.properties from <workingDir> in order 
to get a clean setup? I can't see that it is getting expanded from fitnesse.jar.

If it needs to be removed, then we would need a way to override this behavior, 
preferably using a property.

Attached are two patches. The first patch removes the explicit deletion of 
plugins.properties. The second, alternative patch instead adds a configuration 
property to override the deletion.

This report Mojo should link or copy the FitNesse HTML reports found at 
target/fitnesse/reports

Structure is like this:
    Front page
        --Suite Setup
        --Suite1
        --Suite2

        --SuiteTearDown

Need some config which will allow the running of both Suite1 and Suite2
<plugin>
                <groupId>uk.co.javahelp.fitnesse</groupId>
                <artifactId>fitnesse-launcher-maven-plugin</artifactId>
                <version>1.2.1</version>
                <configuration>
                    <port>${fitnesse.port}</port>
                    <workingDir>workDir</workingDir>
                    <root>${fitnesse.root}</root>
                    <createSymLink>true</createSymLink>
                    <suite>FrontPage</suite>
                </configuration>

 I tried something like this:  "<suite>FrontPage.Suite1</suite>"  or  "<suite>FrontPage/Suite1</suite>" , but this did not work.

What steps will reproduce the problem?
1. Launch Fitnesse using plugin (mvn clean verify -P wiki)
2. Open Suite which have sub-suites and tests with different tags
2. Go to Tools and select Search
3. Enter Tag Name (regression) in the Search Property section
4. Hit Search

What is the expected output? What do you see instead?
Expected: Should filter and display all Suites/Tests with tag "regression"
Actual: No pages matched your search criteria.
To save this search as a link, paste the text below into a page.

[[Search below !-LibraryCollection-! for 
<description>][ReM.UserInterface.LibraryCollection?searchForm]]

What version of the product are you using? On what operating system?
maven 3.0.5
fitnesse 20121220
plugin 1.3.0


Please provide any additional information below.
I'm able to run specific suites/tests based on tags like below in integrated 
mode but am not able to filter results in wiki mode. 

$> mvn clean verify –P auto -Dfitnesse.suiteFilter=regression

Hello,

It would be very nice if we had a parameter in plugin configuration that would 
allow us to break Maven build if any FitNesse test fails, which should be very 
useful when using this plugin on Jenkins or any CI tool.

The configuration parameter could be like 
<breakBuildOnFailure>true</breakBuildOnFailure> (spotted in the trinidad maven 
plugin).

Thanks.

It would be nice if the bootstrap style for wiki mode could be enabled.

Currently the needed CSS files are not extracted from fitnesse.jar when 
executing set-up goal.

After automated tests are run, the JUnit XML results can be found at 
target/fitnesse/results. This Mojo should then format a site report similar to 
the Surefire / Failsafe reports.

See http://maven.apache.org/surefire/maven-surefire-plugin/api.html

Date: 8 November 2013 21:55
Subject: run-test goal

Is there a way to remove the parameters debu=true, nohistory=true and 
format=java when running run-test goal in your maven pluglin? These parameters 
cause an error when i have mocking codes in my fixture.

thanks,

---------------------------------------------

Date: 20 March 2014 16:35
Subject: fitnesse-launcher-maven-plugin

The only thing that prevents us from fully using it is that in certain cases we 
use the fitlibraryserver, which apparently doesn't work when fitnesse is 
launched in debug mode. The plugin is hardcoded to always set debug=true, do 
you have any plans to add that as an option in the configuration section?

Regards

---------------------------------------------

Currently, if the project is run from somewhere under C:\Documents and 
Settings\username\project,
it will fail

So the end-user project doesn't have to re-duplicate all the dependencies, in 
the situation where they are similar / don't clash

The attached patch updates fitnesse-launcher-maven-plugin to use latest 
fitnesse version 20131110.

ie, the command 'mvn fitnesse:set-up fitnesse:wiki' will launch vanilla FitNesse

What steps will reproduce the problem?
1. My specific setup involved spring-orm.
2. It depends on many jars, most of them <optional>
3. Hibernate 3 and 4 are included. But both are <optional>. Since <optional> is 
ignored by <useProjectDependencies>, both of these jars are in my classpath. 
Neither should be.

What is the expected output? What do you see instead?
To only have required jars in the fitnesse classpath. All jars, <optional> or 
not.

What version of the product are you using? On what operating system?
Latest. Windows and Linux.


Please provide any additional information below.
At first I thought it was due to me not understanding compile, runtime, system, 
test... But no. I tried every combination. "compile" should work, but it gets 
too many jars.

Too many jars!!!

Hi,

I have upgraded fitnesse-launcher-maven-plugin version from 1.4.0 to 1.4.2 and 
found fitnesse theme not working. 

Please assist me on this.

Thx.
Satish

Is there a way to set the hostname to something other than localhost?

Hi,

I'm trying to integrate Fitnesse in our maven lifecycle.
We need to include jacoco in our integration test execution.
But for this we need to fork from Maven JVM.
I download your code and I see you use an option to set runInProcess to false.

May I suggest to add a 'fork' attribute in your run-tests goal in your next 
1.4.3 release like the maven compiler plugin do.

Please find attach the modification.

Regards,
Edouard Lemaistre

See discussion thread:
https://groups.google.com/forum/#!topic/fitnesse-launcher-maven-plugin/yEGJaj3nR
Dk

Custom classes are in project source, and they are appearing in FitNesse's 
classpath, but FitNesse is not picking these classes up as plugins, and when 
you boot FitNesse through the fitnesse-launcher, you do not see the expected 
"Custom Comparators loaded:" ouput.

Apparently the plugins.properties file is never actually loaded.

Running fitnesse-launcher-maven-plugin:1.3.0:set-up fails with

[ERROR] Failed to execute goal 
uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up 
(fitnesse-tests) on project fitnesse-integration-test: Execution fitnesse-tests 
of goal uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up 
failed: An API incompatibility was encountered while executing 
uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up: 
java.lang.NoSuchMethodError: 
org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aeth
er/RepositorySystemSession;

Maven 3.1.1
Mac OS X 10.8.5
Java(TM) SE Runtime Environment (build 1.7.0_21-b12)

It works with maven 3.0.4.

What steps will reproduce the problem?
1. Set up a POM where the set-up goal is executed, without defining the 
${fitnesse.working} property.

What is the expected output? What do you see instead?
I would expect to see the set-up goal use the <workingDir> configuration 
element for any temporary file placement.

Instead, I see the following:
main:
     [move] Warning: Could not find file c:\alloc-fit\${fitnesse.working}\Resources\FitNesseRoot to copy.

This seems to be due to code in SetUpMojo.java where the maven-antrun-plugin is 
used:
https://code.google.com/p/fitnesse-launcher-maven-plugin/source/browse/tags/fitn
esse-launcher-maven-plugin-1.2.1/src/main/java/uk/co/javahelp/maven/plugin/fitne
sse/mojo/SetUpMojo.java#167

What version of the product are you using? On what operating system?
1.2.1

Please provide any additional information below.

http://maven.apache.org/plugin-developers/common-bugs.html#Using_System_Properti
es

This possibly applies to 
uk.co.javahelp.maven.plugin.fitnesse.mojo.AbstractFitNesseMojo.exportProperties(
)

What steps will reproduce the problem?
1. Configure a Maven project to run FitNesse tests with 
fitnesse-launcher-maven-plugin
2. Create a custom FitNesse fixture in src/test/java
3. Create a FitNesse test that uses the custom fixture

What is the expected output? What do you see instead?

When I run the FitNesse in either wiki mode or run-test mode, the test gets an 
exception saying that it cannot find the fixture.  

What version of the product are you using? On what operating system?

I have seen this behavior with both the deployed 1.1.0-SNAPSHOT and a build 
from the latest source code.

Please provide any additional information below.

I am just assuming that the scenario that I'm describing (a fixture in the same 
project as the FitNesse tests) is reasonable.  I tried putting my fixtures in a 
separate Maven project and had the project with the FitNesse tests depend on 
that other project and it worked fine.  If that is the expected/support use 
case, I can live with that.

However, if the plugin should support testing fixtures from the same project as 
the FitNesse tests, I did a little hacking and modified the plugin to add 
${project.build.directory}/test-classes to the maven.classpath.  When I ran 
with the modified plugin, the FitNesse tests ran successfully in wiki mode.  
For some reason, the test still fails with "could not find fixture" in 
run-tests even though the plugin clearly logs that test-classes is on the 
maven.classpath.  It's acting as if ${maven.classpath} isn't expanded in the 
test.  I don't quite understand it.

Anyway, I've attached my diff for your consideration.

Thanks,

Dave

This is a question or maybe a request for an enhancement.

This plugin currently copies file into the folder specified fitnesse.root.  Is 
there anyway to avoid this copying?

I add a table to the root page and when I start the server the next time the 
file is overwritten and I loose the table which is added.

Some projects may prefer to avoid using FitNesse SymLink to hook in their test 
suites into the FitNesse working directory.

A project can set '<createSymLink>true</createSymLink>' and then use 
maven-resources-plugin:copy-resources to copy specific FitNesse wiki pages into 
/target/fitnesse/FitNesseRoot.

Even if a project does use SymLinks, this would also still have to be done for 
the correct deployment of plugins.properties.

The current (1.4.0) java example project shows both of these examples in the 
pom.xml, but it is very verbose configuration.

For convenience, we could perhaps have some config similar to:
  <plugin>
      <groupId>uk.co.javahelp.fitnesse</groupId>
      <artifactId>fitnesse-launcher-maven-plugin</artifactId>
      <configuration>
          <pluginsProperties>
              <copy-resource>true</copy-resource>
              <location>src/test/fitnesse</location>
              <!-- See also Issue #22, regarding cleanup of plugins.properties -->
          </pluginsProperties>
<!-- Would copy MyTestSuite + all children to top of ${fitnesse.workingDir} -->
          <wiki>MyTestSuite</wiki>
<!-- Would copy AnIndividualTest correctly nested to 
${fitnesse.workingDir}/MyTestSuite/NestedSuite/AnIndividualTest -->
          <wiki>MyTestSuite.NestedSuite.AnIndividualTest</wiki>
 <!-- Would copy AnIndividualTest un-nested to top, as in ${fitnesse.workingDir}/AnIndividualTest -->
          <wiki>MyTestSuite/NestedSuite/AnIndividualTest</wiki>
      </configuration>
  </plugin>

What steps will reproduce the problem?
1. Create a test slim fitnesse fixture.
2. Call 
PowerMockAgentTestInitializer.initialize(CDSSingleNameContractConductorTest.clas
s); from the contruction or static initializer
3. Run the "run-tests" goal

What is the expected output? PowerMockito should be loaded successfully just 
like when you run the fixture manually through the wiki page.

What do you see instead?
An exception java.lang.NoClassDefFoundError: 
org/powermock/core/transformers/impl/MainMockTransformer is thrown. Upon 
debugging, the powermock libraries are not being loaded. However, it is already 
defined in the !path which was automatically declared by the plugin.


What version of the product are you using?  1.3.0

On what operating system? Windows 7


Please provide any additional information below.
It seems like the run-test goal is not loading the jars in !path into the 
classpath which causes the no class def fuond error.

Thanks,
Pipo

Hello, there.

First off, I really like this Maven plugin.  I've been interested in FitNesse 
for a long time and I'm now starting a project where I think FitNesse will be a 
good fit for testing.  I went looking for a Maven plugin to run and develop the 
tests and this one looks to be the best.

I started using the 1.0.0 version that is deployed to release Sonatype and I 
didn't get very far.  I found the latest source and I like what the set-up and 
tear-down goals have to offer.  However, I noticed that the 1.1.0-SNAPSHOT code 
appears to have not been deployed to the snapshot repository:

https://oss.sonatype.org/content/repositories/snapshots/uk/co/javahelp/fitnesse/
fitnesse-launcher-maven-plugin/

When you have a moment, would you be willing to deploy a build from the latest 
source code to the snapshot repository?  I'd love to use it in my project.

Thanks,

Dave

Currently (1.4.0-SNAPSHOT) the default config option of 
'<createSymLink>true</createSymLink>' will create a FitNesse SymLink directly 
from its working directory to the test suite under src/test/fitnesse.

If there are other project specific FitNesse wiki pages currently they have to 
be copied into /target/fitnesse/FitNesseRoot using 
maven-resources-plugin:copy-resources.

Perhaps we could have some config similar to:
  <plugin>
      <groupId>uk.co.javahelp.fitnesse</groupId>
      <artifactId>fitnesse-launcher-maven-plugin</artifactId>
      <configuration>
          <suite>MyTestSuite</suite>
          <SymLinks>
              <SymLink>
                  <linkName>JavaExample</linkName>
                  <linkPath>src/test/fitnesse/JavaExample</linkPath>
              </SymLink>
          </SymLinks>
      </configuration>
  </plugin>

Because the plugin currently uses a couple of customised FitNesse bootstrap 
classes, some attention would have to be paid to how much the FitNesse code 
changes between their releases.

Not yet sure what the overall strategy would be. It might need an adaptor 
pattern for the bootstrap classes, or perhaps some kind of plugin internal dumb 
launch and relying on the FitNesse URL's staying constant.

Or we may be stuck with tying plugin versions down to FitNesse versions.

In any situation, it would be best to maintain an internal mapping of 
compatible versions so that the plugin could handle configurations more 
gracefully.

The config option might be something like:
<showTestExceptions>true|false</showTestExceptions>

Data about Exceptions are available in 'target/fitnesse/reports/*.html'

This output can be captured and logged to the console during the 'verify' goal.

Fit Exceptions look like this:
<td class="error">setPostcode<hr/> <span 
class="fit_label">java.lang.IllegalStateException: TEST EXCEPTION</span></td>

Slim Exceptions look like this:

        </tr><tr class="exception-detail closed-detail"><td colspan="5"><pre>__EXCEPTION__:java.lang.IllegalStateException: TEST EXCEPTION
        at anubhava.Address.setPostcode(Address.java:139) [file:/home/stewart/workspace/fitnesse-launcher/fitnesse-launcher-java-example/target/classes/]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
        at fitnesse.slim.fixtureInteraction.DefaultInteraction.methodInvoke(DefaultInteraction.java:16) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.callMethod(MethodExecutor.java:43) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.invokeMethod(MethodExecutor.java:30) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.findAndInvoke(MethodExecutor.java:52) [fitnesse-20130530.jar]
        at fitnesse.slim.FixtureMethodExecutor.execute(FixtureMethodExecutor.java:20) [fitnesse-20130530.jar]
        at fitnesse.slim.StatementExecutor.getMethodExecutionResult(StatementExecutor.java:120) [fitnesse-20130530.jar]
        at fitnesse.slim.StatementExecutor.call(StatementExecutor.java:98) [fitnesse-20130530.jar]
        at fitnesse.slim.instructions.CallInstruction.executeInternal(CallInstruction.java:35) [fitnesse-20130530.jar]
        at fitnesse.slim.instructions.Instruction.execute(Instruction.java:30) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor$Executive.executeStatement(ListExecutor.java:50) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor$Executive.executeStatements(ListExecutor.java:44) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor.execute(ListExecutor.java:84) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.executeInstructions(SlimServer.java:107) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.processTheInstructions(SlimServer.java:94) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.processOneSetOfInstructions(SlimServer.java:68) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.tryProcessInstructions(SlimServer.java:54) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.serve(SlimServer.java:40) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimService.accept(SlimService.java:112) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimService$1.run(SlimService.java:50) [fitnesse-20130530.jar]
Caused by: java.lang.NullPointerException: NESTED
        at anubhava.Address.setPostcode(Address.java:139) [file:/home/stewart/workspace/fitnesse-launcher/fitnesse-launcher-java-example/target/classes/]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
        at fitnesse.slim.fixtureInteraction.DefaultInteraction.methodInvoke(DefaultInteraction.java:16) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.callMethod(MethodExecutor.java:43) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.invokeMethod(MethodExecutor.java:30) [fitnesse-20130530.jar]
        at fitnesse.slim.MethodExecutor.findAndInvoke(MethodExecutor.java:52) [fitnesse-20130530.jar]
        at fitnesse.slim.FixtureMethodExecutor.execute(FixtureMethodExecutor.java:20) [fitnesse-20130530.jar]
        at fitnesse.slim.StatementExecutor.getMethodExecutionResult(StatementExecutor.java:120) [fitnesse-20130530.jar]
        at fitnesse.slim.StatementExecutor.call(StatementExecutor.java:98) [fitnesse-20130530.jar]
        at fitnesse.slim.instructions.CallInstruction.executeInternal(CallInstruction.java:35) [fitnesse-20130530.jar]
        at fitnesse.slim.instructions.Instruction.execute(Instruction.java:30) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor$Executive.executeStatement(ListExecutor.java:50) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor$Executive.executeStatements(ListExecutor.java:44) [fitnesse-20130530.jar]
        at fitnesse.slim.ListExecutor.execute(ListExecutor.java:84) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.executeInstructions(SlimServer.java:107) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.processTheInstructions(SlimServer.java:94) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.processOneSetOfInstructions(SlimServer.java:68) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.tryProcessInstructions(SlimServer.java:54) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimServer.serve(SlimServer.java:40) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimService.accept(SlimService.java:112) [fitnesse-20130530.jar]
        at fitnesse.slim.SlimService$1.run(SlimService.java:50) [fitnesse-20130530.jar]</pre></td></tr>