There were problems with the previous structure that led to the
splitting of these samples. With all the files together in a
single module, the only way to allow the samples to run "out of
the box" in the binary distro was to place the client/application
code that used the extension in the same jar as the extension
itself, which does not show how people should actually build a
new extension. There were various emails to the list last week
about this and the separation into two samples seemed like the
best solution.
I would like to keep the "split" structure as it currently is
rather than make a last minute change just before the 0.90 RC
without opportunity for discussion. (I'm on a plane tomorrow so
I won't have any email access all day.) I am fine with the
proposed renaming of the samples as suggested:
- echo-binding to echo-binding-extension
- echo-binding-appl to echo-binding
- implementation-crud to implementation-crud-extension
- implementation-crud-client to implementation-crud
Adding the "extension" suffix to the extension samples makes the
purpose of these samples clearer and solves the awkwardness over
how to describe the non-extension code.
The purpose of the junit test code in the "client/appl" samples is to
ensure that the client code runs successfully. The only way to test
this is by actually invoking the client code. At present the sample
client code is very similar to the junit test client code, but over
time I would expect more divergence. If it is considered undesirable
to ship a junit test for the client code as part of the samples, then
we could put it under sca/itest/samples as I originally suggested.
It was moved to its current location after discussion on the list
last week. Note that the extension sample modules contain "normal"
junit test code to ensure the extension is loaded and functional.
I agree with making the client/application packages different from
the extension packages. This had been discussed and agreed on the
list and it should have already been that way.
I'd like to better understand the comment about putting test resources
into src/test/resources. In both implementation-crud-client and
binding-echo-appl, the only resources are the composites, and these
are used by the client/application code in src/main. The junit tests
invoke the client code, and the client code uses these resources.
The client code also uses these resources even when it is invoked
directly from the command line and not from the junit tests. So I
don't think it would be correct to move these composites from
src/main to src/test.
Simon
Raymond Feng wrote:
Hi,
The main purposes of the implementation-crud and binding-echo are to
demonstrate how to add new implementation and binding types using the
extension SPIs. As part of that, we have some code to show/verfiy how
the extensions are used and runnable with the Tuscany runtime in the
format of test case. I suggest that we keep each of them a single module
instead of splitting into two which seems to me a bit over-killed.
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, May 19, 2007 10:15 AM
Subject: Re: Cleaning up some of the new sample modules
ant elder wrote:
On 5/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I'd like to do a little bit of cleanup of the new sample modules that
we've added to better separate the sample extensions and the samples
showing how to use them.
I'll make the following changes:
- add missing files and directories to svn:ignore properties
- move test resources to src/test/resources
- use different packages for the client code and the extension code
- rename the composite files to <composite name>.composite as this is
the convention we've adopted for all other samples
- change the test cases in implementation-crud-client and
binding-echo-appl to look like normal test cases (instead of invoking
the client.main methods)
I'll make these changes in the trunk and will merge them into the 0.90
branch.
I'd also like to see better names for these modules:
- implementation-crud-client is not really a client as it contains the
CRUD component in addition to a client
- binding-echo-appl is an application, like the other one it contains a
client and the component that it invokes, but we've tried to not use
the
term application in the other samples
- today somebody pinged me to ask me where he could find our extension
samples, so I'm gathering from it that it's not clear that crud and
echo
are these samples
To address this, I'd like to rename:
- echo-binding to echo-binding-extension
- echo-binding-appl to echo-binding
- implementation-crud to implementation-crud-extension
- implementation-crud-client to implementation-crud
--
Jean-Sebastien
When are you going to do this? I was planning to tag and build the
release
RC today (now).
...ant
I just made the first set of changes to clean up these modules and
will merge them to the branch next.
I'm not sure about the second set of changes to rename these sample
modules. I'm starting to think that we're over complicating these
samples by splitting them in 2 modules for each extension. I preferred
when we just had one implementation-crud module and one echo-binding
module.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
