On 5/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
Simon Laws wrote: > So let me try and summarize... > > All samples will be: > > samples/ > src/ > main/ > sample code > client code (non-junit) > test/ > junit tests > Does this mean that client code would become part of the jars for sample extensions like implementation-crud and binding-echo? This does not seem right to me. I believe this is why the client code for these samples was placed in src/test not src/main. If it is going to be moved to src/main, then I think we should set up ant and mvn to put some src/main files in the jar and leave some as separate classes to keep the extension jars "pure".
It does mean that the client code becomes part of the jar. Suggested in order to satisfy the desire to be able to ship the jar and run from the command line with neither ant or maven. An alternative to this slight impasse that we have would be to create three new samples. binding-echo-client databinding-echo-client implementation-crud-client and treat these as normal mvn projects with client code under main and junit code under test. Of course we have a logical dependency between, for example, binding-echo-client and binding-echo. Also these client projects are not really samples in their own right but simply clients for the extension samples.
ant compile - compile the sample > ant (run) - run the sample > ant test - run the Junit tests > I thought we had agreed it was going to be ant (compile) to compile the sample ant run to run it This makes the ant and mvn targets consistent.
OK, sounds good.
mvn - compile the sample > mvn test - run the Junit tests > > I can fix the current samples to follow the pattern above by. Happy to do > this if we agree. > > I'm still not clear on the point about separate itests to test the client > code. Why can't we introduce the sample run as part of the sample mvn > lifecycle? > I'm not sure how to do this (not saying that it can't be done). However, this would require some customization of the sample poms and I think it's better to keep these standard. By putting the code that runs these sample clients in itest/samples, we can follow the normal mvn pattern of building src/main and running src/test as JUnit tests. Also, this keeps the automated test code for the sample clients (which could become more sophisticated over time, e.g., with output checking) out of the samples themselves, which is good IMO.
I guess I don't agree that testing client code separately is a good thing. In all but the extension samples I feel that the client is an intrinsic part of the sample and should be tested there. I'm happy to complete the work I started on the itest/samples
modules if we are all agreed on this approach. Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
simon
