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".
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.
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'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]
