Comments on: Some FitNesse tricks: Classpath and debugging http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/ Johannes Brodwall's Musings on Software Architecture and Programming Fri, 27 Jan 2012 09:40:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Joe Hoover http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-127593 Joe Hoover Thu, 11 Jun 2009 03:33:05 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-127593 Just built this on OS X with Intellij. Had to remove the quotes around the classpath elements and then it worked. Also seems like Intellij attached automatically when launching RunFitnesse in debug mode. Hit a breakpoint in InheritClasspathTestResponder, this without adding DebugTestResponder. Very nice, thanks. Just built this on OS X with Intellij. Had to remove the quotes around the classpath elements and then it worked. Also seems like Intellij attached automatically when launching RunFitnesse in debug mode. Hit a breakpoint in InheritClasspathTestResponder, this without adding DebugTestResponder. Very nice, thanks.

]]> By: Joe Hoover http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-125182 Joe Hoover Wed, 10 Jun 2009 20:33:05 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-125182 Just built this on OS X with Intellij. Had to remove the quotes around the classpath elements and then it worked. Also seems like Intellij attached automatically when launching RunFitnesse in debug mode. Hit a breakpoint in InheritClasspathTestResponder, this without adding DebugTestResponder. Very nice, thanks. Just built this on OS X with Intellij. Had to remove the quotes around the classpath elements and then it worked. Also seems like Intellij attached automatically when launching RunFitnesse in debug mode. Hit a breakpoint in InheritClasspathTestResponder, this without adding DebugTestResponder. Very nice, thanks.

]]> By: Andy Palmer http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-118040 Andy Palmer Tue, 07 Apr 2009 12:13:07 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-118040 If you use<br>!path {java.class.path}<br>You get the classpath that fitnesse was called with, without the need for changing the fitnesse code.<br><br>Also, if you create a page with the following (eg. .DebugSettings)<br>!define COMMAND_PATTERN {java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 -cp %p %m}<br><br>Then, on pages you want to debug, you can just add<br>!include .DebugSettings<br><br>not as nice as a Debug responder, but solves the problem without writing code for FitNesse. If you use
!path {java.class.path}
You get the classpath that fitnesse was called with, without the need for changing the fitnesse code.

Also, if you create a page with the following (eg. .DebugSettings)
!define COMMAND_PATTERN {java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 -cp %p %m}

Then, on pages you want to debug, you can just add
!include .DebugSettings

not as nice as a Debug responder, but solves the problem without writing code for FitNesse.

]]> By: Johannes Brodwall http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-30046 Johannes Brodwall Fri, 28 Mar 2008 02:48:22 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-30046 Hei, Nils-Helge Using plain old Fit is indeed an option that I considered, too. But now I am actually glad I didn't. I hope you'll like to try out the code from this article. FitNesse is definitely not designed with embedding and extending in mind. But when I was willing to dive into it, I found it wasn't that bad. I really wish my "trick" with writing my own main class was closer to the intended use, though. Hei, Nils-Helge

Using plain old Fit is indeed an option that I considered, too. But now I am actually glad I didn’t. I hope you’ll like to try out the code from this article.

FitNesse is definitely not designed with embedding and extending in mind. But when I was willing to dive into it, I found it wasn’t that bad. I really wish my “trick” with writing my own main class was closer to the intended use, though.

]]> By: Johannes Brodwall http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-84389 Johannes Brodwall Fri, 28 Mar 2008 00:48:22 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-84389 Hei, Nils-Helge<br><br>Using plain old Fit is indeed an option that I considered, too. But now I am actually glad I didn't. I hope you'll like to try out the code from this article.<br><br>FitNesse is definitely not designed with embedding and extending in mind. But when I was willing to dive into it, I found it wasn't that bad. I really wish my "trick" with writing my own main class was closer to the intended use, though. Hei, Nils-Helge

Using plain old Fit is indeed an option that I considered, too. But now I am actually glad I didn't. I hope you'll like to try out the code from this article.

FitNesse is definitely not designed with embedding and extending in mind. But when I was willing to dive into it, I found it wasn't that bad. I really wish my “trick” with writing my own main class was closer to the intended use, though.

]]> By: Nils-Helge Garli Hegvik http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-29849 Nils-Helge Garli Hegvik Thu, 27 Mar 2008 09:58:04 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-29849 As the author of the fitnesse plugin that Ole Morten kindly enough has mentioned, I do agree with you that it is pretty obvious that FitNesse was not built with Maven in mind, and worse, it's practically impossible to customize! It's not modular and extensible at all (you wouldn't believe the troubles and hacks I had to go through to get that thing to work...)! Anyway, you seem to have found a good solution for running FitNesse for a Maven project. I still think there's cases where the pom widget is useful, especially when having a common FitNesse server installation and multiple projects within it. As for me, I've left FitNesse and use plain Fit instead. We use Excel spreadsheets as the source and convert them to HTML tables when the tests are run. Then our build run Fit with these converted HTML tables. It's fast, simple and more importantly, just what we need. As the author of the fitnesse plugin that Ole Morten kindly enough has mentioned, I do agree with you that it is pretty obvious that FitNesse was not built with Maven in mind, and worse, it’s practically impossible to customize! It’s not modular and extensible at all (you wouldn’t believe the troubles and hacks I had to go through to get that thing to work…)!

Anyway, you seem to have found a good solution for running FitNesse for a Maven project. I still think there’s cases where the pom widget is useful, especially when having a common FitNesse server installation and multiple projects within it.

As for me, I’ve left FitNesse and use plain Fit instead. We use Excel spreadsheets as the source and convert them to HTML tables when the tests are run. Then our build run Fit with these converted HTML tables. It’s fast, simple and more importantly, just what we need.

]]> By: Nils-Helge Garli Hegvik http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-84388 Nils-Helge Garli Hegvik Thu, 27 Mar 2008 07:58:04 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-84388 As the author of the fitnesse plugin that Ole Morten kindly enough has mentioned, I do agree with you that it is pretty obvious that FitNesse was not built with Maven in mind, and worse, it's practically impossible to customize! It's not modular and extensible at all (you wouldn't believe the troubles and hacks I had to go through to get that thing to work...)! <br><br>Anyway, you seem to have found a good solution for running FitNesse for a Maven project. I still think there's cases where the pom widget is useful, especially when having a common FitNesse server installation and multiple projects within it.<br><br>As for me, I've left FitNesse and use plain Fit instead. We use Excel spreadsheets as the source and convert them to HTML tables when the tests are run. Then our build run Fit with these converted HTML tables. It's fast, simple and more importantly, just what we need. As the author of the fitnesse plugin that Ole Morten kindly enough has mentioned, I do agree with you that it is pretty obvious that FitNesse was not built with Maven in mind, and worse, it's practically impossible to customize! It's not modular and extensible at all (you wouldn't believe the troubles and hacks I had to go through to get that thing to work…)!

Anyway, you seem to have found a good solution for running FitNesse for a Maven project. I still think there's cases where the pom widget is useful, especially when having a common FitNesse server installation and multiple projects within it.

As for me, I've left FitNesse and use plain Fit instead. We use Excel spreadsheets as the source and convert them to HTML tables when the tests are run. Then our build run Fit with these converted HTML tables. It's fast, simple and more importantly, just what we need.

]]> By: Ole Morten Amundsen http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-29289 Ole Morten Amundsen Mon, 24 Mar 2008 14:19:26 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-29289 I share your philosophy. I want to run everything locally, including the fitnesse server. This is my startup script java -cp fitnesse.jar;lib\fitnesse-pom-widget-1.0-SNAPSHOT.jar;lib\maven-embedder-2.0.4-dep.jar fitnesse.FitNesse -p 8091 -r FitNesseRoot -l logs -o -e 0 Guess you'd find a way to execute the fitness server from Eclipse, but I don't see why. It uses near to nothing of resources and don't need to be restarted to notice updates. A simple .bat or .sh is good enough. RELOCATION I presume you have your fixtures in source control, why not have fitnesse ialongside it? They definetly belong together. /trunk/fitnesse /trunk/fixtures (or wherever the fixtures are located) Then you may use the relative path "!pom ../fixtures/pom.xml" DEBUGGER The option -html fitnesse.html in the debugger outputs the results in the same manner as pressing Test in the fitnesse page. Sadly, there is no cigar with FitNesse. I say, use it to communicate requirements, supplement with a few test tables. It's a wiki, terrible to maintain and opposes refactoring. I've committed my share of sins. Do you have any rules/guidelines for this Johannes? I share your philosophy. I want to run everything locally, including the fitnesse server. This is my startup script

java -cp fitnesse.jar;lib\fitnesse-pom-widget-1.0-SNAPSHOT.jar;lib\maven-embedder-2.0.4-dep.jar fitnesse.FitNesse -p 8091 -r FitNesseRoot -l logs -o -e 0

Guess you’d find a way to execute the fitness server from Eclipse, but I don’t see why. It uses near to nothing of resources and don’t need to be restarted to notice updates. A simple .bat or .sh is good enough.

RELOCATION
I presume you have your fixtures in source control, why not have fitnesse ialongside it? They definetly belong together.

/trunk/fitnesse
/trunk/fixtures (or wherever the fixtures are located)

Then you may use the relative path “!pom ../fixtures/pom.xml”

DEBUGGER
The option -html fitnesse.html in the debugger outputs the results in the same manner as pressing Test in the fitnesse page.

Sadly, there is no cigar with FitNesse. I say, use it to communicate requirements, supplement with a few test tables. It’s a wiki, terrible to maintain and opposes refactoring. I’ve committed my share of sins. Do you have any rules/guidelines for this Johannes?

]]> By: Ole Morten Amundsen http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-84387 Ole Morten Amundsen Mon, 24 Mar 2008 12:19:26 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-84387 I share your philosophy. I want to run everything locally, including the fitnesse server. This is my startup script<br><br>java -cp fitnesse.jar;libfitnesse-pom-widget-1.0-SNAPSHOT.jar;libmaven-embedder-2.0.4-dep.jar fitnesse.FitNesse -p 8091 -r FitNesseRoot -l logs -o -e 0 <br><br>Guess you'd find a way to execute the fitness server from Eclipse, but I don't see why. It uses near to nothing of resources and don't need to be restarted to notice updates. A simple .bat or .sh is good enough.<br><br>RELOCATION<br>I presume you have your fixtures in source control, why not have fitnesse ialongside it? They definetly belong together.<br><br>/trunk/fitnesse<br>/trunk/fixtures (or wherever the fixtures are located)<br><br>Then you may use the relative path "!pom ../fixtures/pom.xml"<br><br>DEBUGGER<br>The option -html fitnesse.html in the debugger outputs the results in the same manner as pressing Test in the fitnesse page.<br><br>Sadly, there is no cigar with FitNesse. I say, use it to communicate requirements, supplement with a few test tables. It's a wiki, terrible to maintain and opposes refactoring. I've committed my share of sins. Do you have any rules/guidelines for this Johannes? I share your philosophy. I want to run everything locally, including the fitnesse server. This is my startup script

java -cp fitnesse.jar;libfitnesse-pom-widget-1.0-SNAPSHOT.jar;libmaven-embedder-2.0.4-dep.jar fitnesse.FitNesse -p 8091 -r FitNesseRoot -l logs -o -e 0

Guess you'd find a way to execute the fitness server from Eclipse, but I don't see why. It uses near to nothing of resources and don't need to be restarted to notice updates. A simple .bat or .sh is good enough.

RELOCATION
I presume you have your fixtures in source control, why not have fitnesse ialongside it? They definetly belong together.

/trunk/fitnesse
/trunk/fixtures (or wherever the fixtures are located)

Then you may use the relative path “!pom ../fixtures/pom.xml”

DEBUGGER
The option -html fitnesse.html in the debugger outputs the results in the same manner as pressing Test in the fitnesse page.

Sadly, there is no cigar with FitNesse. I say, use it to communicate requirements, supplement with a few test tables. It's a wiki, terrible to maintain and opposes refactoring. I've committed my share of sins. Do you have any rules/guidelines for this Johannes?

]]> By: Johannes Brodwall http://johannesbrodwall.com/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/comment-page-1/#comment-29018 Johannes Brodwall Sun, 23 Mar 2008 00:41:29 +0000 http://www.brodwall.com/johannes/blog/2008/03/19/some-fitnesse-tricks-classpath-and-debugging/#comment-29018 Hi, Ole Morten Three reasons why I don't like solutions like the fitnesse-pom-widget: 1. You have to install fitnesse yourself. PLUS: You have to micky around with the installation. For me, maven is my only installer 2. You have to start up stuff with special commands and stuff. For me, Eclipse is my only application runner. 3. You still have to specify a path to the pom that will vary from workstation to workstation in your tests. For me, there is no changes when you relocate the workspace. Close, but no cigar. The debugger is nice, but the result of running the test won't be displayed in your web browser, right? Hi, Ole Morten

Three reasons why I don’t like solutions like the fitnesse-pom-widget:

1. You have to install fitnesse yourself. PLUS: You have to micky around with the installation. For me, maven is my only installer
2. You have to start up stuff with special commands and stuff. For me, Eclipse is my only application runner.
3. You still have to specify a path to the pom that will vary from workstation to workstation in your tests. For me, there is no changes when you relocate the workspace.

Close, but no cigar.

The debugger is nice, but the result of running the test won’t be displayed in your web browser, right?

]]>