Cleaning up some of the new sample modules

[Jean-Sebastien Delfino <js...@apache.org>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[ant elder <an...@gmail.com>]

On 5/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 5/19/07, Jean-Sebastien Delfino <js...@apache.org> 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.


Ok I'll wait till tomorrow to make the RC. IMHO do whatever you think is
best for the extension samples ... :)

   ...ant

Re: Cleaning up some of the new sample modules

[Simon Laws <si...@googlemail.com>]

Hi

I'm all for sorting out the sample naming to bring more consistency but I
would stop short of recombining the application and extension samples. Simon
is right that there we faced technical dilemmas [1] but I'm sure everything
could be made to work however we wanted to lay these samples out. I like the
current layout of

extension sample
  test of extension sample
application that demonstrates extension sample
  test of extension sample application

because it's what I would expect to see as a user.

As a developer of an extension I would develop sufficient tests to convince
myself that the extension works. I might even build an application that uses
it. If I did the latter I would create a separate module.

As a user of the extension I would certainly start with a module that is
separate from the module used to build the extension.

I appreciate that It may be more convenient for us, as infrastructure
developers, to put the application and the extension together but, in my
opinion, this doesn't tell the whole story.

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg17782.html

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

I have created TUSCANY-1356 for this cleanup and attached a patch
for the changes as described below.

   Simon

Simon Nash wrote:

> 
> ant elder wrote:
> 
>> On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>>>
>>>
>>> ant elder wrote:
>>>
>>> > On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>> >
>>> > <snip>
>>> >
>>> >
>>> >>>> Testing that our sample client doesn't fail with an exception is
>>> >>
>>> >> >>> useful to us and may deserve a test in our integration test suite
>>> (if
>>> >> >>> we think that having a proper unit test case testing the bits and
>>> >> >>> pieces in that module is not good enough), but I don't thing that
>>> >> >>> it's interesting to keep it in the sample itself, as it's not 
>>> going
>>> >> >>> to teach anything to an application developer looking at the
>>> sample,
>>> >> >>> and doesn't look like a "normal" unit test case.
>>> >> >>>
>>> >> >> Yes, agreed that this does not really belong in the samples. I
>>> >> would be
>>> >> >> inclined to put this test code in itest/samples, just to have the
>>> >> build
>>> >> >> confirm automatically that all the sample clients actually do run.
>>> >> It's
>>> >> >> good to have equivalent unit tests as well, but the samples are so
>>> >> >> visible
>>> >> >> that I think it's worth testing them explicitly.
>>> >> >>
>>> >> > [snip]
>>> >> >
>>> >> > This is still open. +1 to that suggestion, we do not pollute the
>>> >> samples
>>> >> > themselves with this kind of testing, we need to add new tests 
>>> under
>>> >> > sca/itest/samples that verify that the samples' main methods do not
>>> >> fail.
>>> >> >
>>> >> I volunteer to produce a patch for this.  I'd like to get this into
>>> 0.91.
>>> >
>>> >
>>> >
>>> > If all this is going to do is check a sample main method runs 
>>> without an
>>> > exception does it really matter if it gets in 0.91 or not?
>>> >
>>> The main benefit of getting it into 0.91 is to remove this test code 
>>> from
>>> the sample itself, as it is making the sample slightly confusing.
>>
>>
>>
>>
>> Maybe I've misunderstood whats being proposed, which testcases are being
>> changed?
>>
> Someone has already replaced the client test code that previously
> called main() with a copy of the JUnit test code from the extension
> samples.  So in the implementation-crud sample (using the new naming
> convention) we have CRUDClient.java (correct) and CRUDTestCase.java
> (incorrect, a copy of the same test from implementation-crud-extension,
> and not testing any client code).  This test does use the crud.composite
> file from src/main/resources.  If we had a non-sample itest to exercise
> CRUDClient.java and crud.composite from this sample, we could eliminate
> the duplicate copy of CRUDTestCase.java here.  We could also eliminate
> the dusplicate crud.composite file in implementation-crud-extension by
> having the JUnit test in implementation-crud-extension use the
> crud.composite file from implementation-crud.
> 
> Similarly, in the binding-echo-extension sample, under src/test we
> have duplicates of the implementation code, composite file, and
> JUnit test code from binding-echo.  I'd like to remove this
> duplicate code from binding-echo-extension, have the JUnit tests
> in binding-echo-extension use this code from binding-echo, and
> have a separate itest that excercises EchoBindingClient.java.
> 
> With this approach, all duplicate code is eliminated from the 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
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

ant elder wrote:

> On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
> 
>>
>>
>> ant elder wrote:
>>
>> > On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
>> >
>> > <snip>
>> >
>> >
>> >>>> Testing that our sample client doesn't fail with an exception is
>> >>
>> >> >>> useful to us and may deserve a test in our integration test suite
>> (if
>> >> >>> we think that having a proper unit test case testing the bits and
>> >> >>> pieces in that module is not good enough), but I don't thing that
>> >> >>> it's interesting to keep it in the sample itself, as it's not 
>> going
>> >> >>> to teach anything to an application developer looking at the
>> sample,
>> >> >>> and doesn't look like a "normal" unit test case.
>> >> >>>
>> >> >> Yes, agreed that this does not really belong in the samples. I
>> >> would be
>> >> >> inclined to put this test code in itest/samples, just to have the
>> >> build
>> >> >> confirm automatically that all the sample clients actually do run.
>> >> It's
>> >> >> good to have equivalent unit tests as well, but the samples are so
>> >> >> visible
>> >> >> that I think it's worth testing them explicitly.
>> >> >>
>> >> > [snip]
>> >> >
>> >> > This is still open. +1 to that suggestion, we do not pollute the
>> >> samples
>> >> > themselves with this kind of testing, we need to add new tests under
>> >> > sca/itest/samples that verify that the samples' main methods do not
>> >> fail.
>> >> >
>> >> I volunteer to produce a patch for this.  I'd like to get this into
>> 0.91.
>> >
>> >
>> >
>> > If all this is going to do is check a sample main method runs 
>> without an
>> > exception does it really matter if it gets in 0.91 or not?
>> >
>> The main benefit of getting it into 0.91 is to remove this test code from
>> the sample itself, as it is making the sample slightly confusing.
> 
> 
> 
> Maybe I've misunderstood whats being proposed, which testcases are being
> changed?
> 
Someone has already replaced the client test code that previously
called main() with a copy of the JUnit test code from the extension
samples.  So in the implementation-crud sample (using the new naming
convention) we have CRUDClient.java (correct) and CRUDTestCase.java
(incorrect, a copy of the same test from implementation-crud-extension,
and not testing any client code).  This test does use the crud.composite
file from src/main/resources.  If we had a non-sample itest to exercise
CRUDClient.java and crud.composite from this sample, we could eliminate
the duplicate copy of CRUDTestCase.java here.  We could also eliminate
the dusplicate crud.composite file in implementation-crud-extension by
having the JUnit test in implementation-crud-extension use the
crud.composite file from implementation-crud.

Similarly, in the binding-echo-extension sample, under src/test we
have duplicates of the implementation code, composite file, and
JUnit test code from binding-echo.  I'd like to remove this
duplicate code from binding-echo-extension, have the JUnit tests
in binding-echo-extension use this code from binding-echo, and
have a separate itest that excercises EchoBindingClient.java.

With this approach, all duplicate code is eliminated from the 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



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[ant elder <an...@apache.org>]

On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>
> ant elder wrote:
>
> > On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > <snip>
> >
> >
> >>>> Testing that our sample client doesn't fail with an exception is
> >>
> >> >>> useful to us and may deserve a test in our integration test suite
> (if
> >> >>> we think that having a proper unit test case testing the bits and
> >> >>> pieces in that module is not good enough), but I don't thing that
> >> >>> it's interesting to keep it in the sample itself, as it's not going
> >> >>> to teach anything to an application developer looking at the
> sample,
> >> >>> and doesn't look like a "normal" unit test case.
> >> >>>
> >> >> Yes, agreed that this does not really belong in the samples. I
> >> would be
> >> >> inclined to put this test code in itest/samples, just to have the
> >> build
> >> >> confirm automatically that all the sample clients actually do run.
> >> It's
> >> >> good to have equivalent unit tests as well, but the samples are so
> >> >> visible
> >> >> that I think it's worth testing them explicitly.
> >> >>
> >> > [snip]
> >> >
> >> > This is still open. +1 to that suggestion, we do not pollute the
> >> samples
> >> > themselves with this kind of testing, we need to add new tests under
> >> > sca/itest/samples that verify that the samples' main methods do not
> >> fail.
> >> >
> >> I volunteer to produce a patch for this.  I'd like to get this into
> 0.91.
> >
> >
> >
> > If all this is going to do is check a sample main method runs without an
> > exception does it really matter if it gets in 0.91 or not?
> >
> The main benefit of getting it into 0.91 is to remove this test code from
> the sample itself, as it is making the sample slightly confusing.


Maybe I've misunderstood whats being proposed, which testcases are being
changed?

   ...ant

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

ant elder wrote:

> On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:
> 
> <snip>
> 
> 
>>>> Testing that our sample client doesn't fail with an exception is
>>
>> >>> useful to us and may deserve a test in our integration test suite (if
>> >>> we think that having a proper unit test case testing the bits and
>> >>> pieces in that module is not good enough), but I don't thing that
>> >>> it's interesting to keep it in the sample itself, as it's not going
>> >>> to teach anything to an application developer looking at the sample,
>> >>> and doesn't look like a "normal" unit test case.
>> >>>
>> >> Yes, agreed that this does not really belong in the samples. I 
>> would be
>> >> inclined to put this test code in itest/samples, just to have the 
>> build
>> >> confirm automatically that all the sample clients actually do run. 
>> It's
>> >> good to have equivalent unit tests as well, but the samples are so
>> >> visible
>> >> that I think it's worth testing them explicitly.
>> >>
>> > [snip]
>> >
>> > This is still open. +1 to that suggestion, we do not pollute the 
>> samples
>> > themselves with this kind of testing, we need to add new tests under
>> > sca/itest/samples that verify that the samples' main methods do not
>> fail.
>> >
>> I volunteer to produce a patch for this.  I'd like to get this into 0.91.
> 
> 
> 
> If all this is going to do is check a sample main method runs without an
> exception does it really matter if it gets in 0.91 or not?
> 
The main benefit of getting it into 0.91 is to remove this test code from
the sample itself, as it is making the sample slightly confusing.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[ant elder <an...@apache.org>]

On 6/15/07, Simon Nash <na...@hursley.ibm.com> wrote:

<snip>


>>> Testing that our sample client doesn't fail with an exception is
> >>> useful to us and may deserve a test in our integration test suite (if
> >>> we think that having a proper unit test case testing the bits and
> >>> pieces in that module is not good enough), but I don't thing that
> >>> it's interesting to keep it in the sample itself, as it's not going
> >>> to teach anything to an application developer looking at the sample,
> >>> and doesn't look like a "normal" unit test case.
> >>>
> >> Yes, agreed that this does not really belong in the samples. I would be
> >> inclined to put this test code in itest/samples, just to have the build
> >> confirm automatically that all the sample clients actually do run. It's
> >> good to have equivalent unit tests as well, but the samples are so
> >> visible
> >> that I think it's worth testing them explicitly.
> >>
> > [snip]
> >
> > This is still open. +1 to that suggestion, we do not pollute the samples
> > themselves with this kind of testing, we need to add new tests under
> > sca/itest/samples that verify that the samples' main methods do not
> fail.
> >
> I volunteer to produce a patch for this.  I'd like to get this into 0.91.


If all this is going to do is check a sample main method runs without an
exception does it really matter if it gets in 0.91 or not?

    ...ant

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

Jean-Sebastien Delfino wrote:

> [snip]
> Simon Nash wrote:
> 
>>>>
>>>> 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.
> 
> Done under revision r547139.
> 
Thanks.

> [snip]
> 
>>
>>> Testing that our sample client doesn't fail with an exception is 
>>> useful to us and may deserve a test in our integration test suite (if 
>>> we think that having a proper unit test case testing the bits and 
>>> pieces in that module is not good enough), but I don't thing that 
>>> it's interesting to keep it in the sample itself, as it's not going 
>>> to teach anything to an application developer looking at the sample, 
>>> and doesn't look like a "normal" unit test case.
>>>
>> Yes, agreed that this does not really belong in the samples. I would be
>> inclined to put this test code in itest/samples, just to have the build
>> confirm automatically that all the sample clients actually do run. It's
>> good to have equivalent unit tests as well, but the samples are so 
>> visible
>> that I think it's worth testing them explicitly.
>>
> [snip]
> 
> This is still open. +1 to that suggestion, we do not pollute the samples 
> themselves with this kind of testing, we need to add new tests under 
> sca/itest/samples that verify that the samples' main methods do not fail.
> 
I volunteer to produce a patch for this.  I'd like to get this into 0.91.

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Jean-Sebastien Delfino <js...@apache.org>]

[snip]
Simon Nash wrote:
>>>
>>> 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.
Done under revision r547139.

[snip]
>
>> Testing that our sample client doesn't fail with an exception is 
>> useful to us and may deserve a test in our integration test suite (if 
>> we think that having a proper unit test case testing the bits and 
>> pieces in that module is not good enough), but I don't thing that 
>> it's interesting to keep it in the sample itself, as it's not going 
>> to teach anything to an application developer looking at the sample, 
>> and doesn't look like a "normal" unit test case.
>>
> Yes, agreed that this does not really belong in the samples. I would be
> inclined to put this test code in itest/samples, just to have the build
> confirm automatically that all the sample clients actually do run. It's
> good to have equivalent unit tests as well, but the samples are so 
> visible
> that I think it's worth testing them explicitly.
>
[snip]

This is still open. +1 to that suggestion, we do not pollute the samples 
themselves with this kind of testing, we need to add new tests under 
sca/itest/samples that verify that the samples' main methods do not fail.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

Responses inline.

Jean-Sebastien Delfino wrote:

> Comments inline.
> 
> Simon Nash wrote:
> 
>> 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 apologize if I missed something obvious in the previous discussions, 
> but Is that a problem with the Ant build? Can't we run out of classes 
> outside of the Jar?
> 
Actually it's an issue with the maven build.  By default, the jar
step will put all .class files under target/classes into the jar.  These
classes are the result of compiling all the java code that's under
src/main.  The code under src/test is compiled into target/test-classes,
and maven does not include this code in the jar.

So the options were: 1) put the client/application code into src/test,
which is misleading as it is sample client code and not test code,
or 2) find a way to stop maven from putting all the target/classes code
into the jar.  The latter might have been possible, but neither SimonL
or I knew how to do it, and it seemed cleaner to go with a separate
module (and jar) for the sample application code.

>>
>> 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.
> 
> 
> Now that the release work is done, I'd like to see if we could simplify 
> this in the trunk and reduce the number of modules, then we won't have 
> to find good names for them :)
> 
Quite a few of the samples come in pairs, with client code and server code
or (now) extension code and application code.  I think the most important
thing is for the samples to follow a simple, clear and readily understandable
pattern, and to observe good practice that people will use to develop real
applications and extensions.  If we can reduce the number of modules
without breaking these principles, that's great :-)  In this case, I think
combining the extension and application modules would lead to some loss of
clarity and good structure.

>>
>> 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 think we can use the unit tests to show people:
> - how to test their extension, in implementation-crud
> - how to test the invocation of SCA service components, in 
> implementation-crud-client
> - how to test the client side of an SCA application, by mocking an SCA 
> component, we could do this in implementation-crud-client too, but it'll 
> require some thinking to keep it simple.
> 
There is a very fine line between testing the first of these and testing
the second.  Implementation extensions like implementation-crud are
activated by invocations of SCA service components of that implementation
type.  Can you suggest some other way to test extension code?  Would this
be done with mocking code that drives the extension code using the SPIs?

> Testing that our sample client doesn't fail with an exception is useful 
> to us and may deserve a test in our integration test suite (if we think 
> that having a proper unit test case testing the bits and pieces in that 
> module is not good enough), but I don't thing that it's interesting to 
> keep it in the sample itself, as it's not going to teach anything to an 
> application developer looking at the sample, and doesn't look like a 
> "normal" unit test case.
> 
Yes, agreed that this does not really belong in the samples.  I would be
inclined to put this test code in itest/samples, just to have the build
confirm automatically that all the sample clients actually do run.  It's
good to have equivalent unit tests as well, but the samples are so visible
that I think it's worth testing them explicitly.

>>
>> 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.
> 
> 
> I was talking about 
> incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/crud.composite 
> 
> 
> It was only used by the test case in this module, and I moved it to 
> src/test/resources in revision r539773.
> 
Sorry for misunderstanding.  I thought that you were talking about
resource files in the client/application samples.  This file in
implementation-crud was misplaced, and moving it was a good catch.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Jean-Sebastien Delfino <js...@apache.org>]

Comments inline.

Simon Nash wrote:
> 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 apologize if I missed something obvious in the previous discussions, 
but Is that a problem with the Ant build? Can't we run out of classes 
outside of the Jar?

>
> 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.

Now that the release work is done, I'd like to see if we could simplify 
this in the trunk and reduce the number of modules, then we won't have 
to find good names for them :)

>
> 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 think we can use the unit tests to show people:
- how to test their extension, in implementation-crud
- how to test the invocation of SCA service components, in 
implementation-crud-client
- how to test the client side of an SCA application, by mocking an SCA 
component, we could do this in implementation-crud-client too, but it'll 
require some thinking to keep it simple.

Testing that our sample client doesn't fail with an exception is useful 
to us and may deserve a test in our integration test suite (if we think 
that having a proper unit test case testing the bits and pieces in that 
module is not good enough), but I don't thing that it's interesting to 
keep it in the sample itself, as it's not going to teach anything to an 
application developer looking at the sample, and doesn't look like a 
"normal" unit test case.

>
> 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.

I was talking about 
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/crud.composite

It was only used by the test case in this module, and I moved it to 
src/test/resources in revision r539773.

>
>   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" 
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Simon Nash <na...@hursley.ibm.com>]

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" 
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Raymond Feng <en...@gmail.com>]

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" <js...@apache.org>
To: <tu...@ws.apache.org>
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> On 5/19/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Cleaning up some of the new sample modules

[ant elder <an...@gmail.com>]

On 5/19/07, Jean-Sebastien Delfino <js...@apache.org> 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