On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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.
One of the things I've found confusing with implementation.crud is that because it has a single fixed service interface you can easily just have the component use implementation.java to invoke a CRUD impl and use properties for whatever configuring it needs, so it makes you wonder why using an extension is even necessary. ...ant
