Simon Nash wrote:
>
> ant elder wrote:
>> On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>>
>>> I'm restarting the discussion on this because the previous thread [1]
>>> did not reach a conclusion. I thought it would be useful to
>>> summarize
>>> the issues with the extension samples as they stand, and explain how
>>> the patch for TUSCANY-1356 resolves these issues.
>>>
>>> In the implementation-crud sample (the client application code), we
>>> have
>>> CRUDClient.java, crud.composite, and CRUDTestCase.java.
>>> CRUDClient.java
>>> and crud.composite together provide a sample client that exercises
>>> implementation-crud-extension, and these two files are correctly part
>>> of implementation-crud because they are not part of the extension
>>> jar.
>>> The problem with implementation-crud is the inclusion of
>>> CRUDTestCase.java
>>> ,
>>> which does not use or test any of the above client code, but is just
>>> a
>>> copy of the same file from implementation-crud-extension (and
>>> executed
>>> by mvn when implementation-crud-extension is built). The patch for
>>> TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in
>>> implementation-crud and adds a new itest (not part of the samples)
that
>>> runs the implementation-crud client code to make sure it executes OK.
>>>
>>> The crud.composite file from the implementation-crud sample client
>>> is also
>>> duplicated as part of the test code for
>>> implementation-crud-extension.
>>> There is no need for this code to be duplicated. The patch for
>>> TUSCANY-1356 eliminates this duplicate copy of crud.composite by
having
>>> the JUnit test for implementation-crud-extension use the
crud.composite
>>> file that is part of implementation-crud.
>>>
>>> Similarly, in the binding-echo-extension sample, under src/test
>>> there are
>>> duplicates of the implementation code, composite file, and JUnit
>>> test code
>>> from binding-echo. The patch for TUSCANY-1356 removes duplicate code
>>> from binding-echo-extension by having the JUnit tests in
>>> binding-echo-extension take this code from binding-echo, adds a
>>> non-sample
>>> itest to exercise EchoBindingClient.java from binding-echo, and
removes
>>> redundant JUnit test code from binding-echo (not needed because the
>>> JUnit
>>> tests in binding-echo-extension contains exactly the same code).
>>>
>>> With these changes, all duplicate code is eliminated from these
>>> samples,
>>> all sample code is tested either by sample JUnit tests or separate
>>> itests, and the distinction between the extension and
>>> client/application
>>> samples is much clearer.
>>>
>>> Simon
>>>
>>> [1]
http://www.mail-archive.com/[email protected]/msg19026.html
>>
>>
>>
>> How about instead just deleting the implementation.crud sample? We've
>> the
>> implementation.pojo sample now which seems like a better sample to me
>> anyway.
>>
> The patch for TUSCANY-1356 also corrects similar problems with the
> binding-echo and binding-echo-extension samples. This part of the
> patch
> could be applied while we consider whether or not to delete
> implementation-crud.
>
> I looked at the implementation-pojo-extension sample. It has no
> associated
> client to run "out of the box" using ant. The issues addressed by
> TUSCANY-1356 arose out of the work that was done on
> implementation-crud and
> binding-echo to factor them into an extension sample and
> client/application
> sample so that the client code could run out of the box using ant. If
we
> decide to replace implementation-crud by implementation-pojo, we would
> need
> to fix up implementation-pojo-extension to add a client sample, with
code
> divided between the extension sample and the client sample in the same
> way
> that the patch for TUSCANY-1356 does.
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
I would like to keep implementation-crud as it's showing an
implementation type different from a POJO. Implementation-crud and
implementation-pojo are meant to show different approaches to component
implementations, and I'll be concerned if our only implementation sample
leads all people down the POJO path. If people have serious and concrete
enough issues with implementation-crud, please raise them and we should
take a look at them.
