Hi,
Questions and issues: 1) I noticed your are using very cool plexus which is backbone of maven2.0. How plexus is used? Does it used provide JVM container to load the instrumented jar files? We don't really use plexus, plexus is using us :-) Plexus is the IOC container of maven (ie Spring or Avalon). When you use the goal fitnesse:run, your code will be load in the same JVM that plexus. If you use fitnesse:remotecall your test will be executed in the JVM on your fitnesse server, exactly as if you execute a test with the Html FitNesse interface. 2) In your site, you mention The plugin can't executed the HYPERLINK "http://mojo.codehaus.org/fitnesse-maven-plugin/run-mojo.html"fitnesse:run with FitNesse 20060719. See HYPERLINK "http://jira.codehaus.org/browse/MOJO-778"MOJO-778 for more information. Is this still true. I don't really know. We had this trouble last year on a project. I dont investigate more on this issue, our code was compatible with last previous version. Since this time : 1) I dont try the last FitNesse version 2) Somebody said on the mailing list that it doesn't have any problem. So I don't know, I'm interested by any return from you about it. 3) I know a FitNesse server needs to be running when we use TestRunner to run the FitNesse tests to download the test page. Will the plugin work with FitNesse 20060719 version using fitnesse:remotecall? In fact, the plugin seem to work with the 20060719 version, but some time (I we don't know why) it stays lock, waiting none coming response from the server. When you use it interactively (in dev mode) this is not a problem, you can kill the Java process and go on. Our problem was on our continuous integration server, when some days later we found decades of Java process, locking ram and other resources. 4) We are not quite clear on Classpath provider tag. Suppose if I use maven as classpath provider. How does it work? Does it use ( after resolving) the classpath from the dependencies specified in the pom.xml fie for example for the multiproject example? <classPathProvider>fitnesse</classPathProvider> When you use classPathProvider=fitnesse , the plugin download the classpath you defined in your suite, using the standard fitnesse classpath. Then the plugin use classPathSubstitutions for modifying your server classpath according to the real classpath on the local computer. When you use classPathSubstitutions=maven the plugin ignore the FitNesse server classpath and use instead the maven project classpath. So the response to your last question is yes. I use standard maven dependencies resolution (with transitive dependencies) Regards, Philippe _____ From: Ramaswamy, Pudur [mailto:[EMAIL PROTECTED] Sent: vendredi 21 mars 2008 13:01 To: Philippe Kernevez; Antoine Véret; user@mojo.codehaus.org Subject: RE: fitnesse-maven-plugin - seems not suitable for run-time analysis Thanks Phillppe for your prompt answer. Much appreciated. Only yesterday we made some breakthrough, but we are still having some issues. We made breakthrough because studied your code a little bit if not deep. The issues we found and how we over came it: 1) the clover plug-in defined in the samples does not work with clover licenses. We used latest clover plugin, we need to change the goupid to com.atlassian.maven.plugins 2) After looking at the pom files and reading the source code of your plug-in, we learned that clover is not hooked to your code. It is hooked to pom.xml and you are configuring pom.xml to use clover plug-in to do the needful. We learned that cobertura can also be used, but the goals for cobertura and clover are different. Cobertura does not have aggregate and instrument goals. 3) After understanding that clover is not hooked to your code, we decided to read clover documentation to learn how to do code coverage analysis against J2EE application at run time. Your answer below confirms it. So we just need to specify the full path of the instrumented jar files deployed on tomcat for instance. For example, it will be c:\tomcat\webapps\ROOT\web-inf\lib\NameOfMYrJar-Version-clover.jar 4) We already have very good code coverage using junit and cobertura plugin. We use mock objects for this purpose. However we found bugs while running FitNesse acceptance ( end-to-end) tests which was not caught by unit tests. We like to try your plug-in to get another metric using acceptance tests or fitnesse tests. Questions and issues: 5) I noticed your are using very cool plexus which is backbone of maven2.0. How plexus is used? Does it used provide JVM container to load the instrumented jar files? 6) In your site, you mention The plugin can't executed the HYPERLINK "http://mojo.codehaus.org/fitnesse-maven-plugin/run-mojo.html"fitnesse:run with FitNesse 20060719. See HYPERLINK "http://jira.codehaus.org/browse/MOJO-778"MOJO-778 for more information. Is this still true. 7) I know a FitNesse server needs to be running when we use TestRunner to run the FitNesse tests to download the test page. Will the plugin work with FitNesse 20060719 version using fitnesse:remotecall? 8) We are not quite clear on Classpath provider tag. Suppose if I use maven as classpath provider. How does it work? Does it use ( after resolving) the classpath from the dependencies specified in the pom.xml fie for example for the multiproject example? <classPathProvider>fitnesse</classPathProvider> Thanks, -pudur _____ From: Philippe Kernevez [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 2:13 AM To: Ramaswamy, Pudur; 'Antoine Véret'; user@mojo.codehaus.org Subject: RE: fitnesse-maven-plugin - seems not suitable for run-time analysis Hi, > The question is, is it possible to use your plug-in along with clover and cobertura to get code coverage at run time? Yes, we used it with Clover and provides a sample to do that, but not into a J2EE server. You need to deploy you clover instrumented code into your J2EE server (more information within the maven clover plugin), then use the maven fitnesse plugin for running your suites. In our example, we dont deploy our code into a server, all the container services are moked and we only need a JVM, thats the raison why we can run the goal "fitnesse:run". This configuration is available there (the link was broken) HYPERLINK "http://svn.codehaus.org/mojo/trunk/mojo/fitnesse-maven-plugin/src/it/multip roject/pom.xml"http://svn.codehaus.org/mojo/trunk/mojo/fitnesse-maven-plugin /src/it/multiproject/pom.xml In this case you need to define you fitnesse path using the clover classifier jar instead of the default one (ie NameOfYourJar-Version-clover.jar instead of NameOfYourJar-Version.jar). You need to read the clover plugin documentation HYPERLINK "http://maven.apache.org/plugins/maven-clover-plugin/"http://maven.apache.or g/plugins/maven-clover-plugin/ for building and deploy a war/ear build with clover instrumented code, then call fitnesse:run or fitnesse:remotecall (for executing your test) on a pre-site phase as we do in our sample, then call clover:clover for building the report. Regards, Philippe _____ From: Ramaswamy, Pudur [mailto:[EMAIL PROTECTED] Sent: jeudi 20 mars 2008 18:07 To: Philippe Kernevez; Antoine Véret; user@mojo.codehaus.org Subject: RE: fitnesse-maven-plugin - seems not suitable for run-time analysis Thanks Philippe for your answer. We have been using FiTNesse for about 4 months now. I took a formal training in Scrum and FiTNesse. The doubt in our mind is, when we run our fixtnesse tests against a J2EE application deployed on Tomcat server for example, how can we use your plug-in to measure how much of the code deployed on the server is covered by the fitnesse tests at run time? The question is, is it possible to use your plug-in along with clover and cobertura to get code coverage at run time? Thanks, -pudur _____ From: Philippe Kernevez [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 2:22 AM To: Ramaswamy, Pudur; 'Antoine Véret'; user@mojo.codehaus.org Subject: RE: fitnesse-maven-plugin - seems not suitable for run-time analysis Hi Pudur, FitNesse (HYPERLINK "http://fitnesse.org/"http://fitnesse.org/ ) isn't a code coverage tools. It's an acceptance testing framework. In the FAQ we explain how to integrate it with code coverage tools (for example Clover, JCoverage or Cobertura). We only provide an example with Clover, because it's the only framework I really use with our plugin on a project. You should look at the tools I mentioned previously in my mail. Regards, Philippe _____ From: Ramaswamy, Pudur [mailto:[EMAIL PROTECTED] Sent: mercredi 19 mars 2008 22:37 To: Antoine Véret Cc: [EMAIL PROTECTED] Subject: fitnesse-maven-plugin - seems not suitable for run-time analysis Dear Sirs, After spending quite a bit of time, we are under the impression, the plug-in can only do code coverage at static time not at run-time. We wanted a plug-in or develop one which will do code coverage at run-time when J2EE application is deployed and running on the Tomcat server. Im not sure your plug-in would do in-container run-time code coverage analysis of instrumented jars deployed on the Tomcat server. Any feedback is appreciated. If this can not do run-time analysis, please make this clear in your FAQ. Thanks, -pudur _____ _____ Ce message Envoi est certifié sans virus connu (AVG Pro). Analyse effectuée par AVG. Version: 7.5.519 / Base de données virus: 269.21.7/1335 - Date: 19/03/2008 09:54 Ce message Envoi est certifié sans virus connu (AVG Pro). Analyse effectuée par AVG. Version: 7.5.519 / Base de données virus: 269.21.8/1337 - Date: 20/03/2008 20:10 Ce message Envoi est certifié sans virus connu (AVG Pro). Analyse effectuée par AVG. Version: 7.5.519 / Base de données virus: 269.21.8/1337 - Date: 20/03/2008 20:10
