Comments inline.
Simon
Simon Laws wrote:
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.
My suggestion was much simpler, i.e., that we could keep the client
code out of the sample extension jar and include a .class file for the
client code for these 3 samples in the binary distro. This is similar
to what real users will do when developing extensions.
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.
OK, so we could put the "wrapper" tests that I have been writing in
itest/samples into the samples instead, under src/test. This makes
sense now that we have agreed to include JUnit tests as part of each
sample.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
