I think we may be close to reaching an agreement here :-) See
my response to SimonL's suggestion below.
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.
I think this the right approach for these 3 "extension" samples.
It follows the normal pattern that we have for the other samples that
exercise the extensions that come included with Tuscany SCA, and it
doesn't require any nonstandard variations on maven packaging.
I think it's reasonable to regard these as samples in their own right,
as they show how application developers would take advantage of the
functionality provided by a new extension. Samples that illustrate
the capabilities of a new extension would generally not only contain
client application code, but server application code as well.
If we are all agreed on this approach then I can create these client
projects and post a patch for them. I can also create a patch to put
the "wrapper" JUnit tests for the other sample clients directly into
the sample projects as SimonL has suggested, rather than having them
in a separate itest/samples project.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
