You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/05/08 17:53:07 UTC
Sample READMEs and ant builds
Hi
I'm working steadily through the samples...
- Converting readmes to simple text READMEs and updating where appropriate
- Adding build.xml (or mulitple as required) to provide an ant build for the
binary distribution
- Adding a diagram of the sample composite (not necessary for the
distribution but I always do this for myself as a way of working out what's
going on)
Anyhow. I'm down to calculator-script as I write this. So if anyone want's
to take a look at how its working out and provide feedback that would be
good. If anyone wants to do a few that would be even better ;-)
Regards
Simon
Re: Sample READMEs and ant builds
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 5/11/07, Simon Laws <si...@googlemail.com> wrote:
>
> <snip/>
>
>
>> 4. Don't ship pre-built jars for the samples. With mvn and ant scripts
>> > provided for all the samples, it's really easy for anyone to build
>> > the necessary class and jar files themselves.
>>
>>
>> I'm happy to ditch them and there is a very tiny change to the ant build
>> if
>> they are not there.
>
>
> I really like having the pre-built samples in the binary distro and the
> simplicity they provide by being able to run them out-of-the-box with a
> simple java -cp command. What is the problem with keeping them?
>
> ...ant
>
+1 from me for keeping the pre-built samples in the binary distro.
If I wanted to try out and get a rough idea of what Tuscany and SCA are
about, I would probably do the following:
1. Download and unzip our binary distro
2. Run one or two of the pre-built samples to see if they work
3. Take a look at the sample code
4. Maybe take a look at the Javadoc
So, I think it's useful to have the pre-built samples and be able to run
them without having to install and set up Ant to build them first.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
This makes sense to me if
1) the samples are standalone Java programs (not requiring JUnit)
2) all the necessary executable files needed to run them are
present in the binary distro. For src/main files, these are
currently in the jar file. For src/test files that should not
be included in the jar (the extension samples follow this
pattern), we would need to include .class files, which isn't
happening currently.
3) the simple java -cp command is listed in the readme so that
it can be cut-and-pasted and doesn't need ant any or maven
build script to be run
It does not make sense to me if
1) The samples depend on JUnit. This means that they need more than
a simple java -cp to run them.
2) A build step using ant or maven is needed to create any of the
binary files that are needed to run the samples. This is the case
in the last binary distro that I downloaded.
3) The java -cp command (or commmands if we support different
flavours to run from either jars or classes) is buried inside
an ant or maven build script.
Simon
ant elder wrote:
> On 5/11/07, Simon Laws <si...@googlemail.com> wrote:
>
> <snip/>
>
>
>> 4. Don't ship pre-built jars for the samples. With mvn and ant scripts
>> > provided for all the samples, it's really easy for anyone to build
>> > the necessary class and jar files themselves.
>>
>>
>> I'm happy to ditch them and there is a very tiny change to the ant build
>> if
>> they are not there.
>
>
>
> I really like having the pre-built samples in the binary distro and the
> simplicity they provide by being able to run them out-of-the-box with a
> simple java -cp command. What is the problem with keeping them?
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
On 5/11/07, Simon Laws <si...@googlemail.com> wrote:
<snip/>
> 4. Don't ship pre-built jars for the samples. With mvn and ant scripts
> > provided for all the samples, it's really easy for anyone to build
> > the necessary class and jar files themselves.
>
>
> I'm happy to ditch them and there is a very tiny change to the ant build
> if
> they are not there.
I really like having the pre-built samples in the binary distro and the
simplicity they provide by being able to run them out-of-the-box with a
simple java -cp command. What is the problem with keeping them?
...ant
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
ok - well we can do that and it's pretty much zero change as that is where
we are at the moment, i.e. you have to build the sample before you run it. I
don't think providing ant scripts is a problem as we could make the "run"
target depend on the "compile" target for the three extension samples.
Simon
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
On 5/14/07, Simon Laws <si...@googlemail.com> wrote:
>
> snip
> >
> >
> > My suggestion was much simpler, i.e., that we could keep the client
> > code out of the sample extension jar and include a .class file for the
> > client code for these 3 samples in the binary distro. This is similar
> > to what real users will do when developing extensions.
> >
>
> Making this happen is a little complicated from what I can see. I put the
> client code in the test directory in the first place because I couldn't
> see
> a way of excluding it using pom configuration. I've gone back and had a
> play
> with it and I still can't see how to exclude a class file from a jar file
> using the jar plugin. There maybe something that can be done with the
> assembly plugin but I'm not really familiar with it so maybe one of our
> Maven experts can help?
>
> If we do want to exclude "application" code from the sample extension jar
> (which I grant you does make sense for the extension samples) then we can
> either leave the code where it is in the test dir or put it in another
> sample project. I added this latter proposition because if it's in the
> test
> dir then we don't meet the 'run out of the box from a java command line'
> aspiration that has been expressed previously.
>
> Simon
>
Maybe the extension samples could be treated as special cases that don't
need to be usable out of the box from a java command?
Most of the samples are demonstrating how to use Tuscany and SCA for
applications, and as has been said before in this thread it makes sense to
include the tests to show how you can test your SCA based applications. But
the extensions are extending the Tuscany runtime so it doesn't seem
unreasonable that they aren't quite so simple,
How about we don't ship the binaries of these type of samples, also, as the
runtime requires maven to build how about not even including Ant scripts for
them and just require Maven?
...ant
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Laws wrote:
> snip
>
>>
>>
>> My suggestion was much simpler, i.e., that we could keep the client
>> code out of the sample extension jar and include a .class file for the
>> client code for these 3 samples in the binary distro. This is similar
>> to what real users will do when developing extensions.
>>
>
> Making this happen is a little complicated from what I can see. I put the
> client code in the test directory in the first place because I couldn't see
> a way of excluding it using pom configuration. I've gone back and had a
> play
> with it and I still can't see how to exclude a class file from a jar file
> using the jar plugin. There maybe something that can be done with the
> assembly plugin but I'm not really familiar with it so maybe one of our
> Maven experts can help?
>
I spent a while looking for a way to do this but like you I have come
up empty. It seems that the Maven 1.x jar plugin supports a property
maven.jar.excludes that does this, but this capability is not supported
by the Maven 2.x jar plugin. There's a JIRA issue MJAR-30 for this issue,
but not much sign of interest by the maven developers in addressing this.
> If we do want to exclude "application" code from the sample extension jar
> (which I grant you does make sense for the extension samples) then we can
> either leave the code where it is in the test dir or put it in another
> sample project. I added this latter proposition because if it's in the test
> dir then we don't meet the 'run out of the box from a java command line'
> aspiration that has been expressed previously.
>
Without a maven solution for this, I think you are correct that these
are unfortunately the only options. I'll sleep on this and see if
anything else occurs to me.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
snip
>
>
> My suggestion was much simpler, i.e., that we could keep the client
> code out of the sample extension jar and include a .class file for the
> client code for these 3 samples in the binary distro. This is similar
> to what real users will do when developing extensions.
>
Making this happen is a little complicated from what I can see. I put the
client code in the test directory in the first place because I couldn't see
a way of excluding it using pom configuration. I've gone back and had a play
with it and I still can't see how to exclude a class file from a jar file
using the jar plugin. There maybe something that can be done with the
assembly plugin but I'm not really familiar with it so maybe one of our
Maven experts can help?
If we do want to exclude "application" code from the sample extension jar
(which I grant you does make sense for the extension samples) then we can
either leave the code where it is in the test dir or put it in another
sample project. I added this latter proposition because if it's in the test
dir then we don't meet the 'run out of the box from a java command line'
aspiration that has been expressed previously.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
Simon Laws wrote:
> On 5/13/07, Simon Nash <na...@hursley.ibm.com> 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.
>
My suggestion was much simpler, i.e., that we could keep the client
code out of the sample extension jar and include a .class file for the
client code for these 3 samples in the binary distro. This is similar
to what real users will do when developing extensions.
>> ant compile - compile the sample
>> > ant (run) - run the sample
>> > ant test - run the Junit tests
>> >
>> I thought we had agreed it was going to be
>> ant (compile) to compile the sample
>> ant run to run it
>> This makes the ant and mvn targets consistent.
>
>
>
> OK, sounds good.
>
>> mvn - compile the sample
>> > mvn test - run the Junit tests
>> >
>> > I can fix the current samples to follow the pattern above by. Happy to
>> do
>> > this if we agree.
>> >
>> > I'm still not clear on the point about separate itests to test the
>> client
>> > code. Why can't we introduce the sample run as part of the sample mvn
>> > lifecycle?
>> >
>> I'm not sure how to do this (not saying that it can't be done).
>> However, this would require some customization of the sample
>> poms and I think it's better to keep these standard. By putting
>> the code that runs these sample clients in itest/samples, we can
>> follow the normal mvn pattern of building src/main and running
>> src/test as JUnit tests. Also, this keeps the automated test code
>> for the sample clients (which could become more sophisticated over
>> time, e.g., with output checking) out of the samples themselves,
>> which is good IMO.
>
>
>
> I guess I don't agree that testing client code separately is a good thing.
> In all but the extension samples I feel that the client is an intrinsic
> part
> of the sample and should be tested there.
>
OK, so we could put the "wrapper" tests that I have been writing in
itest/samples into the samples instead, under src/test. This makes
sense now that we have agreed to include JUnit tests as part of each
sample.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
Simon Laws wrote:
> On 5/16/07, Simon Laws <si...@googlemail.com> wrote:
>
>>
>>
>>
>> On 5/16/07, Simon Nash <na...@hursley.ibm.com> wrote:
>> >
>> > Simon,
>> > Thanks for committing this. See comments inline below.
>> >
>> > Simon
>> >
>> > Simon Laws wrote:
>> > > Ok, I took a look at the patch and committed it. I made a few minor
>> > > changes:
>> > >
>> > > package name changed to crud
>> > >
>> > I deliberately changed the package name for the client/application code
>> > to crudClient to make it different from the package name for the CRUD
>> > implementation type. This helps to make it clearer which code is
>> > which, and it is more representative of a typical user scenario
>> > (which the samples are meant to illustrate). I am also doing this
>> > with the client/application samples for binding-echo and
>> > databinding-echo.
>> >
>> > What was the rationale for reversing this change?
>>
>>
>> It was any deep reasoning - just that the capitol C looked strange in the
>> package name so I took the word out altogether. I could have gone for
>> crudclient instead.
>>
I'd be fine with crudclient here, and echoappl instead of echoAppl for the
echo-binding-appl sample. I don't know why I did it the other way; habit
from typing variable names I suppose. I do think it's valuable to give
the client/application code a different package name from the extension code.
>> > include copy of composite file from implementation-crud
>> > >
>> > Thanks, I missed this. I did spot it for binding-echo (see my other
>> > post) but I did not pick up on it for this sample. It should be
>> > removed from sample-implementation-crud.jar as it does not belong
>> > there. Moving it to src/test/resources in the implementation-crud
>> > sample seems to work OK.
>>
>>
>> OK I can fix that.
>>
>> > move diagrams from implementation-crud
>> > >
>> > I didn't do this because I thought it might be a good idea to update
>> > the diagrams to show the client side code as well. What do you think?
>> > What tool do you use to produce these diagrams?
>>
>>
>> I haven't generally put the client code on the diagram. But I could if it
>> makes it clearer. I'm using inkscape to produce the svgs
>>
I think this would help, especially for binding-echo-appl where I still
only have a sketchy idea of what the EchoServer.getServer().sendReceive()
call in EchoBindingClient.java is doing :-)
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
>
>
> No go ahead - I'm testing the other samples at the moment.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I agree that this refactoring is the right approach. I am happy to do this
if you like (and I promise to avoid camel-casing any package names :-)
Let me know if you are OK with this or if you would prefer to do it yourself.
Simon
Simon Laws wrote:
> Looking at the databinding-echo sample I realize now that it is not showing
> how to define a new databinding but using the sample echo binding to show
> how the existing databindings work. However the source code from
> binding-echo is duplicated here which is not great. I propose that instead
> of refactoring this as per binding-echo and implementation-crud we
> modify it
> to remove the duplicated code and replace it with a dependency on the
> binding-echo sample.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
Looking at the databinding-echo sample I realize now that it is not showing
how to define a new databinding but using the sample echo binding to show
how the existing databindings work. However the source code from
binding-echo is duplicated here which is not great. I propose that instead
of refactoring this as per binding-echo and implementation-crud we modify it
to remove the duplicated code and replace it with a dependency on the
binding-echo sample.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
On 5/16/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 5/16/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > Simon,
> > Thanks for committing this. See comments inline below.
> >
> > Simon
> >
> > Simon Laws wrote:
> > > Ok, I took a look at the patch and committed it. I made a few minor
> > > changes:
> > >
> > > package name changed to crud
> > >
> > I deliberately changed the package name for the client/application code
> > to crudClient to make it different from the package name for the CRUD
> > implementation type. This helps to make it clearer which code is
> > which, and it is more representative of a typical user scenario
> > (which the samples are meant to illustrate). I am also doing this
> > with the client/application samples for binding-echo and
> > databinding-echo.
> >
> > What was the rationale for reversing this change?
>
>
> It was any deep reasoning - just that the capitol C looked strange in the
> package name so I took the word out altogether. I could have gone for
> crudclient instead.
>
> > include copy of composite file from implementation-crud
> > >
> > Thanks, I missed this. I did spot it for binding-echo (see my other
> > post) but I did not pick up on it for this sample. It should be
> > removed from sample-implementation-crud.jar as it does not belong
> > there. Moving it to src/test/resources in the implementation-crud
> > sample seems to work OK.
>
>
> OK I can fix that.
>
> > move diagrams from implementation-crud
> > >
> > I didn't do this because I thought it might be a good idea to update
> > the diagrams to show the client side code as well. What do you think?
> > What tool do you use to produce these diagrams?
>
>
> I haven't generally put the client code on the diagram. But I could if it
> makes it clearer. I'm using inkscape to produce the svgs
>
> > But looks good.
> > >
> > > Last update relating to this was at revision 538481.
> > >
> > > The binding-echo and databinding-echo tests will also change to follow
> > this
> > > pattern.
> > >
> > I'm working on these now (having solved my NoSuchMethodError problem)
> > and I will post patches very soon.
>
>
> OK, I started looking at the databinding-echo sample.
>
> Simon
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> ...or even crud.client which would make more sense I guess
Simon
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
On 5/16/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Simon,
> Thanks for committing this. See comments inline below.
>
> Simon
>
> Simon Laws wrote:
> > Ok, I took a look at the patch and committed it. I made a few minor
> > changes:
> >
> > package name changed to crud
> >
> I deliberately changed the package name for the client/application code
> to crudClient to make it different from the package name for the CRUD
> implementation type. This helps to make it clearer which code is
> which, and it is more representative of a typical user scenario
> (which the samples are meant to illustrate). I am also doing this
> with the client/application samples for binding-echo and databinding-echo.
>
> What was the rationale for reversing this change?
It was any deep reasoning - just that the capitol C looked strange in the
package name so I took the word out altogether. I could have gone for
crudclient instead.
> include copy of composite file from implementation-crud
> >
> Thanks, I missed this. I did spot it for binding-echo (see my other
> post) but I did not pick up on it for this sample. It should be
> removed from sample-implementation-crud.jar as it does not belong
> there. Moving it to src/test/resources in the implementation-crud
> sample seems to work OK.
OK I can fix that.
> move diagrams from implementation-crud
> >
> I didn't do this because I thought it might be a good idea to update
> the diagrams to show the client side code as well. What do you think?
> What tool do you use to produce these diagrams?
I haven't generally put the client code on the diagram. But I could if it
makes it clearer. I'm using inkscape to produce the svgs
> But looks good.
> >
> > Last update relating to this was at revision 538481.
> >
> > The binding-echo and databinding-echo tests will also change to follow
> this
> > pattern.
> >
> I'm working on these now (having solved my NoSuchMethodError problem)
> and I will post patches very soon.
OK, I started looking at the databinding-echo sample.
Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon,
Thanks for committing this. See comments inline below.
Simon
Simon Laws wrote:
> Ok, I took a look at the patch and committed it. I made a few minor
> changes:
>
> package name changed to crud
>
I deliberately changed the package name for the client/application code
to crudClient to make it different from the package name for the CRUD
implementation type. This helps to make it clearer which code is
which, and it is more representative of a typical user scenario
(which the samples are meant to illustrate). I am also doing this
with the client/application samples for binding-echo and databinding-echo.
What was the rationale for reversing this change?
> include copy of composite file from implementation-crud
>
Thanks, I missed this. I did spot it for binding-echo (see my other
post) but I did not pick up on it for this sample. It should be
removed from sample-implementation-crud.jar as it does not belong
there. Moving it to src/test/resources in the implementation-crud
sample seems to work OK.
> move diagrams from implementation-crud
>
I didn't do this because I thought it might be a good idea to update
the diagrams to show the client side code as well. What do you think?
What tool do you use to produce these diagrams?
> But looks good.
>
> Last update relating to this was at revision 538481.
>
> The binding-echo and databinding-echo tests will also change to follow this
> pattern.
>
I'm working on these now (having solved my NoSuchMethodError problem)
and I will post patches very soon.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
Ok, I took a look at the patch and committed it. I made a few minor changes:
package name changed to crud
include copy of composite file from implementation-crud
move diagrams from implementation-crud
But looks good.
Last update relating to this was at revision 538481.
The binding-echo and databinding-echo tests will also change to follow this
pattern.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I have completed the implementation-crud-client sample (see patch for
TUSCANY-1287). Everything is working.
I have completed the code for binding-echo-appl but the application
client does not run because of the NoSuchMethodError that I reported
to the list.
When working on binding-echo-appl I noticed a problem with the current
packaging of binding-echo. The sample-binding-echo.jar file contains
EchoBinding.composite, which is incorrect as this is not part of the
binding extension. It is part of the sample application code that
exercises the binding extension and therefore belongs in
sample-binding-echo-appl.jar as part of the new binding-echo-appl sample.
Simon
Simon Laws wrote:
> Ok sounds good to me. Assuming everyone is happy for this to go in now we
> can tidy this up pretty quickly I think. If SimonN creates three new
> projects to hold the client/application code for the extension samples I'm
> happy to take a look at the patches and commit. I can also go and fix up
> the
> existing Ant/Maven files as we move the client code from the 3 extension
> samples to new sample dirs. For the time being I think we need to leave the
> component implementation in both extension samples and client samples so
> that the JUnit tests that exists in the extension samples still work. The
> client code will move though. So what we are left with gives us a test
> layout that is clear and consistent and easy to describe to the potential
> user but, at the moment, with minimal content.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
Ok sounds good to me. Assuming everyone is happy for this to go in now we
can tidy this up pretty quickly I think. If SimonN creates three new
projects to hold the client/application code for the extension samples I'm
happy to take a look at the patches and commit. I can also go and fix up the
existing Ant/Maven files as we move the client code from the 3 extension
samples to new sample dirs. For the time being I think we need to leave the
component implementation in both extension samples and client samples so
that the JUnit tests that exists in the extension samples still work. The
client code will move though. So what we are left with gives us a test
layout that is clear and consistent and easy to describe to the potential
user but, at the moment, with minimal content.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
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 <na...@hursley.ibm.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
On 5/13/07, Simon Nash <na...@hursley.ibm.com> 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.
> ant compile - compile the sample
> > ant (run) - run the sample
> > ant test - run the Junit tests
> >
> I thought we had agreed it was going to be
> ant (compile) to compile the sample
> ant run to run it
> This makes the ant and mvn targets consistent.
OK, sounds good.
> mvn - compile the sample
> > mvn test - run the Junit tests
> >
> > I can fix the current samples to follow the pattern above by. Happy to
> do
> > this if we agree.
> >
> > I'm still not clear on the point about separate itests to test the
> client
> > code. Why can't we introduce the sample run as part of the sample mvn
> > lifecycle?
> >
> I'm not sure how to do this (not saying that it can't be done).
> However, this would require some customization of the sample
> poms and I think it's better to keep these standard. By putting
> the code that runs these sample clients in itest/samples, we can
> follow the normal mvn pattern of building src/main and running
> src/test as JUnit tests. Also, this keeps the automated test code
> for the sample clients (which could become more sophisticated over
> time, e.g., with output checking) out of the samples themselves,
> which is good IMO.
I guess I don't agree that testing client code separately is a good thing.
In all but the extension samples I feel that the client is an intrinsic part
of the sample and should be tested there.
I'm happy to complete the work I started on the itest/samples
> modules if we are all agreed on this approach.
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
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".
> ant compile - compile the sample
> ant (run) - run the sample
> ant test - run the Junit tests
>
I thought we had agreed it was going to be
ant (compile) to compile the sample
ant run to run it
This makes the ant and mvn targets consistent.
> mvn - compile the sample
> mvn test - run the Junit tests
>
> I can fix the current samples to follow the pattern above by. Happy to do
> this if we agree.
>
> I'm still not clear on the point about separate itests to test the client
> code. Why can't we introduce the sample run as part of the sample mvn
> lifecycle?
>
I'm not sure how to do this (not saying that it can't be done).
However, this would require some customization of the sample
poms and I think it's better to keep these standard. By putting
the code that runs these sample clients in itest/samples, we can
follow the normal mvn pattern of building src/main and running
src/test as JUnit tests. Also, this keeps the automated test code
for the sample clients (which could become more sophisticated over
time, e.g., with output checking) out of the samples themselves,
which is good IMO.
I'm happy to complete the work I started on the itest/samples
modules if we are all agreed on this approach.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
So let me try and summarize...
All samples will be:
samples/
src/
main/
sample code
client code (non-junit)
test/
junit tests
ant compile - compile the sample
ant (run) - run the sample
ant test - run the Junit tests
mvn - compile the sample
mvn test - run the Junit tests
I can fix the current samples to follow the pattern above by. Happy to do
this if we agree.
I'm still not clear on the point about separate itests to test the client
code. Why can't we introduce the sample run as part of the sample mvn
lifecycle?
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Yes, in the patch that I posted for TUSCANY-1264, this is exactly
what the JUnit tests in sca/itest/samples do. Not perfect, but
better than nothing. It may be possible to add some level of
output checking, but I haven't attempted this yet.
Simon
Jean-Sebastien Delfino wrote:
> [snip]
> Simon Nash wrote:
>
>>
>>>
>> It exercises the non-JUnit sample client code to make sure it runs.
>>
>>
>
> Ah OK, I understand now :) I'm +1 on having these separate itests as
> well then. Are we just going to make sure that they run without throwing
> exceptions?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Nash wrote:
>
>>
> It exercises the non-JUnit sample client code to make sure it runs.
>
>
Ah OK, I understand now :) I'm +1 on having these separate itests as
well then. Are we just going to make sure that they run without throwing
exceptions?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
Jean-Sebastien Delfino wrote:
> Comments inline.
>
> Simon Laws wrote:
>
>> I think there is a difference in the way that we are looking at these
>> samples.
>>
>> - We could consider that the samples are purely to show SCA running in
>> various scenarios and nothing more, i.e. anything extra such as sample
>> tests
>> or extra build steps is superfluous.
>> - Alternatively we could consider the samples to be a demonstration
>> of, not
>> only the function of the SCA runtime, but of how you might start to build
>> software that uses SCA, for example, you will likely need some tests
>> and you
>> will want to be able to integrate the sample into your IDE of choice.
>
>
> I prefer that approach. SCA is a programming model for application
> developers. Samples show how you use develop an application. Test is an
> important part of development :) So I think we should have Junit test
> cases as part of the sample code.
>
I'm OK with this as long as they are distinct from the samples.
I'd think of these as "sample tests".
>>
>> I have been thinking along the latter lines and stepping back I'm
>> thinking
>> maybe we need to do more on testing rather than less, i.e. include a
>> JUnit
>> target in the ant script. We also need some more IDE detail and I've
>> already
>> marked this as a TODO in the top level samples README.
>
>
> An Ant test target would be nice to have, but not mandatory for this
> release IMO. Even with an Ant target I think we should keep the current
> structure, which I believe follows common development practice: tests in
> a separate directory, and not packaged in target JARs or a binary distro.
>
Agreed.
>>
>> Anyhow I think this is why we seem to be coming at this from different
>> angles. So probably need others opinions to see which way to go.
>>
>> Some more comments in line taking this into account.
>>
>> On 5/11/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>>>
>>> Thanks for the detailed review and comments. My responses are inline.
>>>
>>> Simon
>>>
>>> Simon Laws wrote:
>>>
>>> > Hi, I was thinking about this problem the other way round
>>> >
>>> > At the moment the binary distribution builds with the following
>>> structure
>>> > (taking binding-echo and simple-bigbank as two examples)
>>> >
>>> > docs/
>>> > lib/
>>> > modules/
>>> > samples/
>>> > binding-echo
>>> > src/
>>> > main/
>>> > extension sample code
>>> > test/
>>> > java/
>>> > echo/
>>> > EchoBindingClient.java
>>> > EchoReferenceTestCase.java
>>> > EchoServiceTestCase.java
>>> > simple-bigbank/
>>> > src/
>>> > main/
>>> > java/
>>> > bigbank/
>>> > client/
>>> > BigBankClient.java
>>> > test/
>>> > java/
>>> > bigbank/
>>> > BigBankTestCase.java
>>> >
>>> > So there are a number of issues we have been discussing
>>> >
>>> > 1/ Should there be JUnit tests in the samples.
>>> > 2/ Should the mvn poms distributed with the binary distribution run
>>> the
>>> > sample client used by the Ant build instead of/as well as the JUnit
>>> test
>>> > 3/ If you look at the binding-echo test (and the other extension
>>> example
>>> > tests) you see I put the clients used by ant in the test directory.
>>> This
>>> is
>>> > inconsistent with the rest of the samples but consistent with the
>>> desire
>>> to
>>> > demonstrate here how to build an extension, rather than how to build a
>>> > client.
>>> >
>>> > My 2c on these
>>> > 1/ I don't mind there being JUnit tests in the samples. I would bow to
>>> > consensus if it's generally thought that this complicates the first
>>> use
>>> > experience but as a java developer I know what a junit test is and
>>> it's
>>> > quite nice to have a test on which to base new tests that I may use
>>> with
>>> > any
>>> > changes I make
>>> >
>
>
> Having test cases in the samples does not complicate them IMO if they
> are in separate src/test directories. It also helps application
> developers understand how to test an SCA application.
>
I agree with keeping the tests separate from the client code.
>
>>> If it is desirable for the samples to provide a Junit-style template,
>>> I could easily restructure the client code to follow the JUnit
>>> pattern of
>>> having setUp(), testXXX() and tearDown() methods, invoked in turn by the
>>> main() method.
>
>
> I'm not sure I understand this. In a normal application, main() would
> not call Junit test code. Junit tests would be on the side, sometimes
> duplicating a little bit what the application is doing, for test
> purposes with assertions to test expected results. I don't think that
> having the application main() reuse test code is common practice, and it
> will probably not work as test code is usually not packaged with the
> application anyway.
>
This suggestion was in response to SimonL's point that people will
appreciate having a template that can be used to create their own
JUnit tests. I was suggesting a way that we could ship one piece of
client code that can run without JUnit but would have a JUnit-like
structure to also serve as that template. We are now converging
around a different approach of keeping clients and tests completely
separate, and in that environment this suggestion would not apply.
>>>
>>> I think the most important thing to decide is whether it's useful for
>>> samples (as opposed to tests) to use JUnit directly or follow a
>>> JUnit-like
>>> structure. I think we should go with the consensus on this. I don't
>>> think
>>> we should clutter the samples with JUnit tests and non-JUnit clients
>>> that
>>> both contain almost identical code.
>>
>>
>
> Let's think about how an application developer will develop the same
> kind of application. He will write a main method(). He will write
> separate test cases with more assertions around the business logic. He
> may have to duplicate 6 or 7 lines of code between the main() and the
> junit test but it's not necessarily bad.
>
I think it depends how much is duplicated. In some of the samples,
the client-side logic is more or less identical between clients and
tests (and I'm not just talking about the "boilerplate" code at the
start and end). If we can improve these samples to have more realistic
client code and test code, in which the test code would not be virtually
the same as the client code, then I am fine with some minor amount of
duplication betwween these.
> Having the main() method call the test code is very confusing IMO and
> not common practice.
> Reorganizing the sample into separate methods, maybe more classes, just
> to reuse 6 or 7 lines will probably look more complicated in the end.
> If we move the tests out of the samples then they'll miss one important
> part of development, testing...
>
See my comments above on this.
>>
>> As I come from the second point of view I support having tests in the
>> samples. I can imagine that the clients and the JUnit tests would
>> diverge to
>> alow for more imaginative sample outout than we have now.
>
>
> +1 Yes, for example prints in the main, assertions in the test.
>
Agreed. I also think tests should exercise more cases and conditions,
whereas sample client code should focus more on clarity of exposition,
showing how to achieve a practical piece of functionality.
>>
>>> 2/ I think people running ant and mvn expect different things. I.e.
>>> having
>>> > mvn run the junit tests run is not unexpected to a maven user. We may
>>> > choose
>>> > to have the poms here run the ant client as well for completeness,
>>> e.gwe
>>> > could engage your wrappers to do this.
>>> >
>>> This is what the sca/itest/samples poms are doing now in the code I
>>> posted.
>>> I don't think this should becaome part of the sca/samples poms
>>> because it
>>> pollutes the samples even more with artifacts that are there for test
>>> purposes.
>>>
>>> > 3/ This was the basis of my original question. The tests are not
>>> shipped
>>> in
>>> > the sample jars (I still need to find out why) to the effect is
>>> that the
>>> > client is missed from the sample jar and the three extension example
>>> tests
>>> > don't run out of the box. Due to the clients location I constructed
>>> the
>>> ant
>>> > scripts to build the test directory but had to filter out the unit
>>> tests
>>> > because JUnit does not ship. I would rather solve these problems by
>>> moving
>>> > the client code into main/ than removing the JUnit tests altogether.
>>> >
>
>
> Not including the test code in the target JARs is common practice, as
> tests are run as part of the build process, but you obviously don't want
> them in the finished prodiuct.
>
> If one or two samples have put their client code in src/test, then they
> need to fixed and this client code should move to src/main. If there is
> no client with a main() but only a test case, then the sample is
> incomplete and a client with a main() should be added, but I don't think
> that we should change the whole packaging strategy and try to twist
> Maven's arm to include test code in the JARs just to make these
> incorrect samples work. IMO we should try to fix the samples first.
>
Agreed.
>>> It seems strange to me that we are including the jar files in the distro
>>> but not the compiled standalone class files from src/test. The sample
>>> pom.xml files solve this problem for maven users by forcing a recompile
>>> of src/main and src/test before running the sample. (This makes it
>>> pretty much pointless including the jars as part of the distributed
>>> samples, as they always get rebuilt in this step). This doesn't require
>>> the src/test classes to be part of the jar file. We could do the
>>> same in
>>> build.xml for ant builds.
>>
>>
>>
>> We can just flick the ant build over to make the run target depend on the
>> compile target to get the effect you have described.
>>
It takes a bit more than that as the "compile" target currently
doesn't compile the test classes.
>>> I took a look at the code. Some comments:
>>> >
>>> > - I like the idea of the wrappers but I would maybe use them as
>>> well as
>>> the
>>> > junit tests rather than instead of.
>>> >
>>> It's a nuisance to maintain two sets of almost identical code, and
>>> rather
>>> confusing for the user if we deliver both in the samples. I think it's
>>> better to pick one flavour.
>>>
>> I would like to see the client and test code diverge to make the clients
>> more meaningful from a sample point of view.
>
>
> Yes, me too. I'm not surprised to see test code follow the same steps
> and exercise the same methods as the main application code, with a few
> more checkings and assertions.
>
> This is what application developers will do in their applications
> anyway. They will have a main() and separate test cases, containing
> variations of similar code for different purposes.
>
See my comments above on this. The devil is in the details here.
I don't think the code should be almost identical between sample
clients and JUnit tests except for assertions and displaying output.
There will be some similar patterns, but tests should exercise many
more variations on the same theme (e.g., different argument values)
to cover different potential failure scenarios, whereas sample code
should focus more on showing best practice for common use cases and
providing a template for what application writers will want to do
in their applications.
>>> - The effect of removing the JUnit tests from the samples is that the
>>
>>
>>> > samples don't get tested anymore. Well not to the extent that the
>>> > assertions
>>> > that are currently included in the JUnit tests are exercised
>>>
>>> Good point. For tests, this is important. For samples, displaying the
>>> result to the console is better than running a silent assertion. It's
>>> things like this that make me think we should make a distinction
>>> between tests and samples. The wrapper approach does run all the
>>> samples as part of the build, but doesn't currently do any validation
>>> of the results.
>>>
>>> > - The itests aren't shipped at the moment in the binary release
>>> AFAIK so
>>> > the
>>> > maven based samples wouldn't be available. We could fix this of
>>> course
>>> but
>>> > would need discussion at this stage.
>>> >
>
>
> Tests are usually not shipped with binaries. JUnit tests are run as part
> of a build. If you build, you start from the source again.
>
Agreed.
>>> By maven-based samples I presume you mean samples that run when you
>>> type mvn. With the code I checked in, mvn builds the samples but
>>> doesn't run them. I'm confident that I could come up with a small pom
>>> change that would run them as well (not within Junit), if that is
>>> desired.
>>>
>>> There's a lot of discussion here. For clarity, here's what I think we
>>> should do.
>>>
>>> 1. Have the ant and mvn sample builds do the same thing or close to
>>> the same thing.
>>
>>
>>
>> Think that sounds like a good idea but I include tests in that.
>
>
> +1 and +1 to include the tests in that.
>
I'm OK with including the tests, if we separate the tests and client code
as discussed above.
>>
>> 2. Have both of these run a non-junit sample client, after compiling
>>
>>> any necessary files first.
>>
>>
>>
>> see 1
>
>
> All client samples should have a non-Junit sample client.
> ant run -> run that client
> ant test -> run the Junit tests
> mvn -> does not run anything
> mvn test -> run the Junit tests
>
Agreed. I presume that "ant" would just build and not run, so that
it is the same as "mvn" (see above discussion about ant and mvn doing
the same). The current pom.xml and build.xml will need to be changed
to make things work this way.
>>
>> 3. Divide sample code between src/main and src/test on the basis of what
>>
>>> makes most sense for the reader (remembering that these are
>>> samples).
>>> For samples that build a jar that will be used as a runtime
>>> extension,
>>> putting the test code for this extension into src/test and keeping
>>> it out of the jar file seems best. For "standalone" samples that
>>> consist of 100% test code, it seems best to avoid splitting this
>>> code
>>> into src/main and src/test categories (pick either one). I don't
>>> think there's any need to build a jar in these cases.
>>
>>
>
> I would prefer to keep the test cases in src/test in all cases, as it's
> common practice and will make more sense to the reader.
>
Agreed.
>>
>> I believe that the configuration we have now embodies this thinking
>>
>> 4. Don't ship pre-built jars for the samples. With mvn and ant scripts
>>
>>> provided for all the samples, it's really easy for anyone to build
>>> the necessary class and jar files themselves.
>>
>>
>
> Already responded to this one in a separate thread. I would prefer to
> keep to pre-build samples.
>
See my other post on this on a separate thread.
>>
>> I'm happy to ditch them and there is a very tiny change to the ant
>> build if
>> they are not there.
>>
>> 5. Have the itest/samples module do automated testing of the samples
>>
>>> as part of the build, using Junit.
>
>
> If we keep the test cases in the samples. What does that bring us?
>
It exercises the non-JUnit sample client code to make sure it runs.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Simon Laws wrote:
> I think there is a difference in the way that we are looking at these
> samples.
>
> - We could consider that the samples are purely to show SCA running in
> various scenarios and nothing more, i.e. anything extra such as sample
> tests
> or extra build steps is superfluous.
> - Alternatively we could consider the samples to be a demonstration
> of, not
> only the function of the SCA runtime, but of how you might start to build
> software that uses SCA, for example, you will likely need some tests
> and you
> will want to be able to integrate the sample into your IDE of choice.
I prefer that approach. SCA is a programming model for application
developers. Samples show how you use develop an application. Test is an
important part of development :) So I think we should have Junit test
cases as part of the sample code.
>
> I have been thinking along the latter lines and stepping back I'm
> thinking
> maybe we need to do more on testing rather than less, i.e. include a
> JUnit
> target in the ant script. We also need some more IDE detail and I've
> already
> marked this as a TODO in the top level samples README.
An Ant test target would be nice to have, but not mandatory for this
release IMO. Even with an Ant target I think we should keep the current
structure, which I believe follows common development practice: tests in
a separate directory, and not packaged in target JARs or a binary distro.
>
> Anyhow I think this is why we seem to be coming at this from different
> angles. So probably need others opinions to see which way to go.
>
> Some more comments in line taking this into account.
>
> On 5/11/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>> Thanks for the detailed review and comments. My responses are inline.
>>
>> Simon
>>
>> Simon Laws wrote:
>>
>> > Hi, I was thinking about this problem the other way round
>> >
>> > At the moment the binary distribution builds with the following
>> structure
>> > (taking binding-echo and simple-bigbank as two examples)
>> >
>> > docs/
>> > lib/
>> > modules/
>> > samples/
>> > binding-echo
>> > src/
>> > main/
>> > extension sample code
>> > test/
>> > java/
>> > echo/
>> > EchoBindingClient.java
>> > EchoReferenceTestCase.java
>> > EchoServiceTestCase.java
>> > simple-bigbank/
>> > src/
>> > main/
>> > java/
>> > bigbank/
>> > client/
>> > BigBankClient.java
>> > test/
>> > java/
>> > bigbank/
>> > BigBankTestCase.java
>> >
>> > So there are a number of issues we have been discussing
>> >
>> > 1/ Should there be JUnit tests in the samples.
>> > 2/ Should the mvn poms distributed with the binary distribution run
>> the
>> > sample client used by the Ant build instead of/as well as the JUnit
>> test
>> > 3/ If you look at the binding-echo test (and the other extension
>> example
>> > tests) you see I put the clients used by ant in the test directory.
>> This
>> is
>> > inconsistent with the rest of the samples but consistent with the
>> desire
>> to
>> > demonstrate here how to build an extension, rather than how to build a
>> > client.
>> >
>> > My 2c on these
>> > 1/ I don't mind there being JUnit tests in the samples. I would bow to
>> > consensus if it's generally thought that this complicates the first
>> use
>> > experience but as a java developer I know what a junit test is and
>> it's
>> > quite nice to have a test on which to base new tests that I may use
>> with
>> > any
>> > changes I make
>> >
Having test cases in the samples does not complicate them IMO if they
are in separate src/test directories. It also helps application
developers understand how to test an SCA application.
>> If it is desirable for the samples to provide a Junit-style template,
>> I could easily restructure the client code to follow the JUnit
>> pattern of
>> having setUp(), testXXX() and tearDown() methods, invoked in turn by the
>> main() method.
I'm not sure I understand this. In a normal application, main() would
not call Junit test code. Junit tests would be on the side, sometimes
duplicating a little bit what the application is doing, for test
purposes with assertions to test expected results. I don't think that
having the application main() reuse test code is common practice, and it
will probably not work as test code is usually not packaged with the
application anyway.
>>
>> I think the most important thing to decide is whether it's useful for
>> samples (as opposed to tests) to use JUnit directly or follow a
>> JUnit-like
>> structure. I think we should go with the consensus on this. I don't
>> think
>> we should clutter the samples with JUnit tests and non-JUnit clients
>> that
>> both contain almost identical code.
>
Let's think about how an application developer will develop the same
kind of application. He will write a main method(). He will write
separate test cases with more assertions around the business logic. He
may have to duplicate 6 or 7 lines of code between the main() and the
junit test but it's not necessarily bad.
Having the main() method call the test code is very confusing IMO and
not common practice.
Reorganizing the sample into separate methods, maybe more classes, just
to reuse 6 or 7 lines will probably look more complicated in the end.
If we move the tests out of the samples then they'll miss one important
part of development, testing...
>
> As I come from the second point of view I support having tests in the
> samples. I can imagine that the clients and the JUnit tests would
> diverge to
> alow for more imaginative sample outout than we have now.
+1 Yes, for example prints in the main, assertions in the test.
>
>> 2/ I think people running ant and mvn expect different things. I.e.
>> having
>> > mvn run the junit tests run is not unexpected to a maven user. We may
>> > choose
>> > to have the poms here run the ant client as well for completeness,
>> e.gwe
>> > could engage your wrappers to do this.
>> >
>> This is what the sca/itest/samples poms are doing now in the code I
>> posted.
>> I don't think this should becaome part of the sca/samples poms
>> because it
>> pollutes the samples even more with artifacts that are there for test
>> purposes.
>>
>> > 3/ This was the basis of my original question. The tests are not
>> shipped
>> in
>> > the sample jars (I still need to find out why) to the effect is
>> that the
>> > client is missed from the sample jar and the three extension example
>> tests
>> > don't run out of the box. Due to the clients location I constructed
>> the
>> ant
>> > scripts to build the test directory but had to filter out the unit
>> tests
>> > because JUnit does not ship. I would rather solve these problems by
>> moving
>> > the client code into main/ than removing the JUnit tests altogether.
>> >
Not including the test code in the target JARs is common practice, as
tests are run as part of the build process, but you obviously don't want
them in the finished prodiuct.
If one or two samples have put their client code in src/test, then they
need to fixed and this client code should move to src/main. If there is
no client with a main() but only a test case, then the sample is
incomplete and a client with a main() should be added, but I don't think
that we should change the whole packaging strategy and try to twist
Maven's arm to include test code in the JARs just to make these
incorrect samples work. IMO we should try to fix the samples first.
>> It seems strange to me that we are including the jar files in the distro
>> but not the compiled standalone class files from src/test. The sample
>> pom.xml files solve this problem for maven users by forcing a recompile
>> of src/main and src/test before running the sample. (This makes it
>> pretty much pointless including the jars as part of the distributed
>> samples, as they always get rebuilt in this step). This doesn't require
>> the src/test classes to be part of the jar file. We could do the
>> same in
>> build.xml for ant builds.
>
>
> We can just flick the ant build over to make the run target depend on the
> compile target to get the effect you have described.
>
>> I took a look at the code. Some comments:
>> >
>> > - I like the idea of the wrappers but I would maybe use them as
>> well as
>> the
>> > junit tests rather than instead of.
>> >
>> It's a nuisance to maintain two sets of almost identical code, and
>> rather
>> confusing for the user if we deliver both in the samples. I think it's
>> better to pick one flavour.
>>
> I would like to see the client and test code diverge to make the clients
> more meaningful from a sample point of view.
Yes, me too. I'm not surprised to see test code follow the same steps
and exercise the same methods as the main application code, with a few
more checkings and assertions.
This is what application developers will do in their applications
anyway. They will have a main() and separate test cases, containing
variations of similar code for different purposes.
>> - The effect of removing the JUnit tests from the samples is that the
>
>> > samples don't get tested anymore. Well not to the extent that the
>> > assertions
>> > that are currently included in the JUnit tests are exercised
>>
>> Good point. For tests, this is important. For samples, displaying the
>> result to the console is better than running a silent assertion. It's
>> things like this that make me think we should make a distinction
>> between tests and samples. The wrapper approach does run all the
>> samples as part of the build, but doesn't currently do any validation
>> of the results.
>>
>> > - The itests aren't shipped at the moment in the binary release
>> AFAIK so
>> > the
>> > maven based samples wouldn't be available. We could fix this of
>> course
>> but
>> > would need discussion at this stage.
>> >
Tests are usually not shipped with binaries. JUnit tests are run as part
of a build. If you build, you start from the source again.
>> By maven-based samples I presume you mean samples that run when you
>> type mvn. With the code I checked in, mvn builds the samples but
>> doesn't run them. I'm confident that I could come up with a small pom
>> change that would run them as well (not within Junit), if that is
>> desired.
>>
>> There's a lot of discussion here. For clarity, here's what I think we
>> should do.
>>
>> 1. Have the ant and mvn sample builds do the same thing or close to
>> the same thing.
>
>
> Think that sounds like a good idea but I include tests in that.
+1 and +1 to include the tests in that.
>
> 2. Have both of these run a non-junit sample client, after compiling
>> any necessary files first.
>
>
> see 1
All client samples should have a non-Junit sample client.
ant run -> run that client
ant test -> run the Junit tests
mvn -> does not run anything
mvn test -> run the Junit tests
>
> 3. Divide sample code between src/main and src/test on the basis of what
>> makes most sense for the reader (remembering that these are
>> samples).
>> For samples that build a jar that will be used as a runtime
>> extension,
>> putting the test code for this extension into src/test and keeping
>> it out of the jar file seems best. For "standalone" samples that
>> consist of 100% test code, it seems best to avoid splitting this
>> code
>> into src/main and src/test categories (pick either one). I don't
>> think there's any need to build a jar in these cases.
>
I would prefer to keep the test cases in src/test in all cases, as it's
common practice and will make more sense to the reader.
>
> I believe that the configuration we have now embodies this thinking
>
> 4. Don't ship pre-built jars for the samples. With mvn and ant scripts
>> provided for all the samples, it's really easy for anyone to build
>> the necessary class and jar files themselves.
>
Already responded to this one in a separate thread. I would prefer to
keep to pre-build samples.
>
> I'm happy to ditch them and there is a very tiny change to the ant
> build if
> they are not there.
>
> 5. Have the itest/samples module do automated testing of the samples
>> as part of the build, using Junit.
If we keep the test cases in the samples. What does that bring us?
>
>
> Comments much appreciated.
>>
>> Simon
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
I think there is a difference in the way that we are looking at these
samples.
- We could consider that the samples are purely to show SCA running in
various scenarios and nothing more, i.e. anything extra such as sample tests
or extra build steps is superfluous.
- Alternatively we could consider the samples to be a demonstration of, not
only the function of the SCA runtime, but of how you might start to build
software that uses SCA, for example, you will likely need some tests and you
will want to be able to integrate the sample into your IDE of choice.
I have been thinking along the latter lines and stepping back I'm thinking
maybe we need to do more on testing rather than less, i.e. include a JUnit
target in the ant script. We also need some more IDE detail and I've already
marked this as a TODO in the top level samples README.
Anyhow I think this is why we seem to be coming at this from different
angles. So probably need others opinions to see which way to go.
Some more comments in line taking this into account.
On 5/11/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Thanks for the detailed review and comments. My responses are inline.
>
> Simon
>
> Simon Laws wrote:
>
> > Hi, I was thinking about this problem the other way round
> >
> > At the moment the binary distribution builds with the following
> structure
> > (taking binding-echo and simple-bigbank as two examples)
> >
> > docs/
> > lib/
> > modules/
> > samples/
> > binding-echo
> > src/
> > main/
> > extension sample code
> > test/
> > java/
> > echo/
> > EchoBindingClient.java
> > EchoReferenceTestCase.java
> > EchoServiceTestCase.java
> > simple-bigbank/
> > src/
> > main/
> > java/
> > bigbank/
> > client/
> > BigBankClient.java
> > test/
> > java/
> > bigbank/
> > BigBankTestCase.java
> >
> > So there are a number of issues we have been discussing
> >
> > 1/ Should there be JUnit tests in the samples.
> > 2/ Should the mvn poms distributed with the binary distribution run the
> > sample client used by the Ant build instead of/as well as the JUnit test
> > 3/ If you look at the binding-echo test (and the other extension example
> > tests) you see I put the clients used by ant in the test directory. This
> is
> > inconsistent with the rest of the samples but consistent with the desire
> to
> > demonstrate here how to build an extension, rather than how to build a
> > client.
> >
> > My 2c on these
> > 1/ I don't mind there being JUnit tests in the samples. I would bow to
> > consensus if it's generally thought that this complicates the first use
> > experience but as a java developer I know what a junit test is and it's
> > quite nice to have a test on which to base new tests that I may use with
> > any
> > changes I make
> >
> If it is desirable for the samples to provide a Junit-style template,
> I could easily restructure the client code to follow the JUnit pattern of
> having setUp(), testXXX() and tearDown() methods, invoked in turn by the
> main() method.
>
> I think the most important thing to decide is whether it's useful for
> samples (as opposed to tests) to use JUnit directly or follow a JUnit-like
> structure. I think we should go with the consensus on this. I don't
> think
> we should clutter the samples with JUnit tests and non-JUnit clients that
> both contain almost identical code.
As I come from the second point of view I support having tests in the
samples. I can imagine that the clients and the JUnit tests would diverge to
alow for more imaginative sample outout than we have now.
> 2/ I think people running ant and mvn expect different things. I.e. having
> > mvn run the junit tests run is not unexpected to a maven user. We may
> > choose
> > to have the poms here run the ant client as well for completeness, e.gwe
> > could engage your wrappers to do this.
> >
> This is what the sca/itest/samples poms are doing now in the code I
> posted.
> I don't think this should becaome part of the sca/samples poms because it
> pollutes the samples even more with artifacts that are there for test
> purposes.
>
> > 3/ This was the basis of my original question. The tests are not shipped
> in
> > the sample jars (I still need to find out why) to the effect is that the
> > client is missed from the sample jar and the three extension example
> tests
> > don't run out of the box. Due to the clients location I constructed the
> ant
> > scripts to build the test directory but had to filter out the unit tests
> > because JUnit does not ship. I would rather solve these problems by
> moving
> > the client code into main/ than removing the JUnit tests altogether.
> >
> It seems strange to me that we are including the jar files in the distro
> but not the compiled standalone class files from src/test. The sample
> pom.xml files solve this problem for maven users by forcing a recompile
> of src/main and src/test before running the sample. (This makes it
> pretty much pointless including the jars as part of the distributed
> samples, as they always get rebuilt in this step). This doesn't require
> the src/test classes to be part of the jar file. We could do the same in
> build.xml for ant builds.
We can just flick the ant build over to make the run target depend on the
compile target to get the effect you have described.
> I took a look at the code. Some comments:
> >
> > - I like the idea of the wrappers but I would maybe use them as well as
> the
> > junit tests rather than instead of.
> >
> It's a nuisance to maintain two sets of almost identical code, and rather
> confusing for the user if we deliver both in the samples. I think it's
> better to pick one flavour.
>
I would like to see the client and test code diverge to make the clients
more meaningful from a sample point of view.
> - The effect of removing the JUnit tests from the samples is that the
> > samples don't get tested anymore. Well not to the extent that the
> > assertions
> > that are currently included in the JUnit tests are exercised
>
> Good point. For tests, this is important. For samples, displaying the
> result to the console is better than running a silent assertion. It's
> things like this that make me think we should make a distinction
> between tests and samples. The wrapper approach does run all the
> samples as part of the build, but doesn't currently do any validation
> of the results.
>
> > - The itests aren't shipped at the moment in the binary release AFAIK so
> > the
> > maven based samples wouldn't be available. We could fix this of course
> but
> > would need discussion at this stage.
> >
> By maven-based samples I presume you mean samples that run when you
> type mvn. With the code I checked in, mvn builds the samples but
> doesn't run them. I'm confident that I could come up with a small pom
> change that would run them as well (not within Junit), if that is desired.
>
> There's a lot of discussion here. For clarity, here's what I think we
> should do.
>
> 1. Have the ant and mvn sample builds do the same thing or close to
> the same thing.
Think that sounds like a good idea but I include tests in that.
2. Have both of these run a non-junit sample client, after compiling
> any necessary files first.
see 1
3. Divide sample code between src/main and src/test on the basis of what
> makes most sense for the reader (remembering that these are samples).
> For samples that build a jar that will be used as a runtime extension,
> putting the test code for this extension into src/test and keeping
> it out of the jar file seems best. For "standalone" samples that
> consist of 100% test code, it seems best to avoid splitting this code
> into src/main and src/test categories (pick either one). I don't
> think there's any need to build a jar in these cases.
I believe that the configuration we have now embodies this thinking
4. Don't ship pre-built jars for the samples. With mvn and ant scripts
> provided for all the samples, it's really easy for anyone to build
> the necessary class and jar files themselves.
I'm happy to ditch them and there is a very tiny change to the ant build if
they are not there.
5. Have the itest/samples module do automated testing of the samples
> as part of the build, using Junit.
Comments much appreciated.
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Ant,
This change is independent of the package renames and can be done
(by me) in parallel to Venkat's work on the renaming.
The key purpose of making this change is not to add the sample itests,
but to remove the junit dependencies from the samples that we publish
in the distribution. I only added the sample itests because of a
previous comment on this thread from SimonL that the automated junit
testing of these samples by the full build should be retained.
Perhaps the two activities can be separated:
1. Remove the junit dependencies from the published samples
2. Add the new sample itests that use junit
Are you OK with putting the first of these changes into 0.90?
Simon
ant elder wrote:
> I like the idea of being able to test all the samples with itests,
> especially if that could go as far as also testing the webapp samples.
>
> The main worry i have with this is that its getting really late to get it
> into the 0.90 release. The package renames have just started and thats
> going
> to take most of today and maybe tomorrow to finish up and get everything
> cleaned up and working again, and we can't easily make and test any code
> changes while thats going on. I was really hoping to keep changes after
> then
> to be only required bug fixes and really small changes like text updates to
> the readme's etc.
>
> What do others think, should we try to get these sample itests into 0.90?
>
> ...ant
>
>
> On 5/11/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>
>> I didn't get any feedback or comments on these changes, so I am
>> going to assume that I am on the right track and I will continue
>> with the conversion of the rest of the samples. If anyone doesn't
>> agree with this, please let me know asap.
>>
>> Simon
>>
>> Simon Nash wrote:
>>
>> > I was able to solve this problem using the "wrapping" approach
>> > without needing to add any src/test code to the jar file. I did
>> > the following to convert implementation-crud:
>> >
>> > 1. Created an implementation-crud module under sca/itest/samples.
>> > 2. Created a pom for this module that uses <testResources> to copy
>> > the contents of samples/implementation-crud/target/test-classes.
>> > 3. Removed src/test/CRUDTestCase.java from samples/implementation-crud.
>> > 4. Created src/test/crud/CRUDTestCase.java in
>> > sca/itest/samples/implementation-crud.
>> > This "wrapper" JUnit test case is as follows:
>> >
>> > package crud;
>> >
>> > import junit.framework.TestCase;
>> >
>> > public class CRUDTestCase extends TestCase {
>> >
>> > public void test() throws Exception {
>> > CRUDClient.main(null);
>> > }
>> > }
>> > 5. That's all! sca/itest/samples/implementation-crud gets the
>> > crud.CRUDClient class from <testResources> and all the extension
>> > implementation classes from the sample-implementation-crud
>> > dependency. There's no need to add any src/test classes to the
>> > jar file.
>> >
>> > I have created TUSCANY-1264 for this change and I have attached a
>> > patch to convert the simple-bigbank and implementation-crud samples.
>> > These samples and itests build and run with maven but I haven't built
>> > a new distribution to verify that the sample ant scripts still work.
>> >
>> > Simon
>> >
>> > Simon Laws wrote:
>> >
>> >>>
>> >>>
>> >>> I've checked in changes to allows the provided jar to be run (and
>> >>> built).
>> >>
>> >>
>> >> Outstanding is the issue of including classes from
>> >> src/test in the sample jar or alternatively moving the application
>> >> classes
>> >> to src/main. This effect of this currently is that
>> >>
>> >> binding.echo
>> >> databinding.echo
>> >> implementation.crud
>> >>
>> >> Don't work out of the box with
>> >>
>> >> ant
>> >>
>> >> You have to do
>> >>
>> >> ant compile
>> >> ant
>> >>
>> >> If we don't want to ship junit in the binary distribution we should
>> move
>> >> them. The binary distribution ships the src for the Junit tests b.t.w.
>> so
>> >> I'm going to take a quick look at why maven isn't packaging the
>> classes.
>> >>
>> >> 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
>>
>>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
I like the idea of being able to test all the samples with itests,
especially if that could go as far as also testing the webapp samples.
The main worry i have with this is that its getting really late to get it
into the 0.90 release. The package renames have just started and thats going
to take most of today and maybe tomorrow to finish up and get everything
cleaned up and working again, and we can't easily make and test any code
changes while thats going on. I was really hoping to keep changes after then
to be only required bug fixes and really small changes like text updates to
the readme's etc.
What do others think, should we try to get these sample itests into 0.90?
...ant
On 5/11/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I didn't get any feedback or comments on these changes, so I am
> going to assume that I am on the right track and I will continue
> with the conversion of the rest of the samples. If anyone doesn't
> agree with this, please let me know asap.
>
> Simon
>
> Simon Nash wrote:
>
> > I was able to solve this problem using the "wrapping" approach
> > without needing to add any src/test code to the jar file. I did
> > the following to convert implementation-crud:
> >
> > 1. Created an implementation-crud module under sca/itest/samples.
> > 2. Created a pom for this module that uses <testResources> to copy
> > the contents of samples/implementation-crud/target/test-classes.
> > 3. Removed src/test/CRUDTestCase.java from samples/implementation-crud.
> > 4. Created src/test/crud/CRUDTestCase.java in
> > sca/itest/samples/implementation-crud.
> > This "wrapper" JUnit test case is as follows:
> >
> > package crud;
> >
> > import junit.framework.TestCase;
> >
> > public class CRUDTestCase extends TestCase {
> >
> > public void test() throws Exception {
> > CRUDClient.main(null);
> > }
> > }
> > 5. That's all! sca/itest/samples/implementation-crud gets the
> > crud.CRUDClient class from <testResources> and all the extension
> > implementation classes from the sample-implementation-crud
> > dependency. There's no need to add any src/test classes to the
> > jar file.
> >
> > I have created TUSCANY-1264 for this change and I have attached a
> > patch to convert the simple-bigbank and implementation-crud samples.
> > These samples and itests build and run with maven but I haven't built
> > a new distribution to verify that the sample ant scripts still work.
> >
> > Simon
> >
> > Simon Laws wrote:
> >
> >>>
> >>>
> >>> I've checked in changes to allows the provided jar to be run (and
> >>> built).
> >>
> >>
> >> Outstanding is the issue of including classes from
> >> src/test in the sample jar or alternatively moving the application
> >> classes
> >> to src/main. This effect of this currently is that
> >>
> >> binding.echo
> >> databinding.echo
> >> implementation.crud
> >>
> >> Don't work out of the box with
> >>
> >> ant
> >>
> >> You have to do
> >>
> >> ant compile
> >> ant
> >>
> >> If we don't want to ship junit in the binary distribution we should
> move
> >> them. The binary distribution ships the src for the Junit tests b.t.w.
> so
> >> I'm going to take a quick look at why maven isn't packaging the
> classes.
> >>
> >> 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: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks for the detailed review and comments. My responses are inline.
Simon
Simon Laws wrote:
> Hi, I was thinking about this problem the other way round
>
> At the moment the binary distribution builds with the following structure
> (taking binding-echo and simple-bigbank as two examples)
>
> docs/
> lib/
> modules/
> samples/
> binding-echo
> src/
> main/
> extension sample code
> test/
> java/
> echo/
> EchoBindingClient.java
> EchoReferenceTestCase.java
> EchoServiceTestCase.java
> simple-bigbank/
> src/
> main/
> java/
> bigbank/
> client/
> BigBankClient.java
> test/
> java/
> bigbank/
> BigBankTestCase.java
>
> So there are a number of issues we have been discussing
>
> 1/ Should there be JUnit tests in the samples.
> 2/ Should the mvn poms distributed with the binary distribution run the
> sample client used by the Ant build instead of/as well as the JUnit test
> 3/ If you look at the binding-echo test (and the other extension example
> tests) you see I put the clients used by ant in the test directory. This is
> inconsistent with the rest of the samples but consistent with the desire to
> demonstrate here how to build an extension, rather than how to build a
> client.
>
> My 2c on these
> 1/ I don't mind there being JUnit tests in the samples. I would bow to
> consensus if it's generally thought that this complicates the first use
> experience but as a java developer I know what a junit test is and it's
> quite nice to have a test on which to base new tests that I may use with
> any
> changes I make
>
If it is desirable for the samples to provide a Junit-style template,
I could easily restructure the client code to follow the JUnit pattern of
having setUp(), testXXX() and tearDown() methods, invoked in turn by the
main() method.
I think the most important thing to decide is whether it's useful for
samples (as opposed to tests) to use JUnit directly or follow a JUnit-like
structure. I think we should go with the consensus on this. I don't think
we should clutter the samples with JUnit tests and non-JUnit clients that
both contain almost identical code.
> 2/ I think people running ant and mvn expect different things. I.e. having
> mvn run the junit tests run is not unexpected to a maven user. We may
> choose
> to have the poms here run the ant client as well for completeness, e.g we
> could engage your wrappers to do this.
>
This is what the sca/itest/samples poms are doing now in the code I posted.
I don't think this should becaome part of the sca/samples poms because it
pollutes the samples even more with artifacts that are there for test
purposes.
> 3/ This was the basis of my original question. The tests are not shipped in
> the sample jars (I still need to find out why) to the effect is that the
> client is missed from the sample jar and the three extension example tests
> don't run out of the box. Due to the clients location I constructed the ant
> scripts to build the test directory but had to filter out the unit tests
> because JUnit does not ship. I would rather solve these problems by moving
> the client code into main/ than removing the JUnit tests altogether.
>
It seems strange to me that we are including the jar files in the distro
but not the compiled standalone class files from src/test. The sample
pom.xml files solve this problem for maven users by forcing a recompile
of src/main and src/test before running the sample. (This makes it
pretty much pointless including the jars as part of the distributed
samples, as they always get rebuilt in this step). This doesn't require
the src/test classes to be part of the jar file. We could do the same in
build.xml for ant builds.
> I took a look at the code. Some comments:
>
> - I like the idea of the wrappers but I would maybe use them as well as the
> junit tests rather than instead of.
>
It's a nuisance to maintain two sets of almost identical code, and rather
confusing for the user if we deliver both in the samples. I think it's
better to pick one flavour.
> - The effect of removing the JUnit tests from the samples is that the
> samples don't get tested anymore. Well not to the extent that the
> assertions
> that are currently included in the JUnit tests are exercised
Good point. For tests, this is important. For samples, displaying the
result to the console is better than running a silent assertion. It's
things like this that make me think we should make a distinction
between tests and samples. The wrapper approach does run all the
samples as part of the build, but doesn't currently do any validation
of the results.
> - The itests aren't shipped at the moment in the binary release AFAIK so
> the
> maven based samples wouldn't be available. We could fix this of course but
> would need discussion at this stage.
>
By maven-based samples I presume you mean samples that run when you
type mvn. With the code I checked in, mvn builds the samples but
doesn't run them. I'm confident that I could come up with a small pom
change that would run them as well (not within Junit), if that is desired.
There's a lot of discussion here. For clarity, here's what I think we
should do.
1. Have the ant and mvn sample builds do the same thing or close to
the same thing.
2. Have both of these run a non-junit sample client, after compiling
any necessary files first.
3. Divide sample code between src/main and src/test on the basis of what
makes most sense for the reader (remembering that these are samples).
For samples that build a jar that will be used as a runtime extension,
putting the test code for this extension into src/test and keeping
it out of the jar file seems best. For "standalone" samples that
consist of 100% test code, it seems best to avoid splitting this code
into src/main and src/test categories (pick either one). I don't
think there's any need to build a jar in these cases.
4. Don't ship pre-built jars for the samples. With mvn and ant scripts
provided for all the samples, it's really easy for anyone to build
the necessary class and jar files themselves.
5. Have the itest/samples module do automated testing of the samples
as part of the build, using Junit.
Comments much appreciated.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
Hi, I was thinking about this problem the other way round
At the moment the binary distribution builds with the following structure
(taking binding-echo and simple-bigbank as two examples)
docs/
lib/
modules/
samples/
binding-echo
src/
main/
extension sample code
test/
java/
echo/
EchoBindingClient.java
EchoReferenceTestCase.java
EchoServiceTestCase.java
simple-bigbank/
src/
main/
java/
bigbank/
client/
BigBankClient.java
test/
java/
bigbank/
BigBankTestCase.java
So there are a number of issues we have been discussing
1/ Should there be JUnit tests in the samples.
2/ Should the mvn poms distributed with the binary distribution run the
sample client used by the Ant build instead of/as well as the JUnit test
3/ If you look at the binding-echo test (and the other extension example
tests) you see I put the clients used by ant in the test directory. This is
inconsistent with the rest of the samples but consistent with the desire to
demonstrate here how to build an extension, rather than how to build a
client.
My 2c on these
1/ I don't mind there being JUnit tests in the samples. I would bow to
consensus if it's generally thought that this complicates the first use
experience but as a java developer I know what a junit test is and it's
quite nice to have a test on which to base new tests that I may use with any
changes I make
2/ I think people running ant and mvn expect different things. I.e. having
mvn run the junit tests run is not unexpected to a maven user. We may choose
to have the poms here run the ant client as well for completeness, e.g we
could engage your wrappers to do this.
3/ This was the basis of my original question. The tests are not shipped in
the sample jars (I still need to find out why) to the effect is that the
client is missed from the sample jar and the three extension example tests
don't run out of the box. Due to the clients location I constructed the ant
scripts to build the test directory but had to filter out the unit tests
because JUnit does not ship. I would rather solve these problems by moving
the client code into main/ than removing the JUnit tests altogether.
I took a look at the code. Some comments:
- I like the idea of the wrappers but I would maybe use them as well as the
junit tests rather than instead of.
- The effect of removing the JUnit tests from the samples is that the
samples don't get tested anymore. Well not to the extent that the assertions
that are currently included in the JUnit tests are exercised
- The itests aren't shipped at the moment in the binary release AFAIK so the
maven based samples wouldn't be available. We could fix this of course but
would need discussion at this stage.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I didn't get any feedback or comments on these changes, so I am
going to assume that I am on the right track and I will continue
with the conversion of the rest of the samples. If anyone doesn't
agree with this, please let me know asap.
Simon
Simon Nash wrote:
> I was able to solve this problem using the "wrapping" approach
> without needing to add any src/test code to the jar file. I did
> the following to convert implementation-crud:
>
> 1. Created an implementation-crud module under sca/itest/samples.
> 2. Created a pom for this module that uses <testResources> to copy
> the contents of samples/implementation-crud/target/test-classes.
> 3. Removed src/test/CRUDTestCase.java from samples/implementation-crud.
> 4. Created src/test/crud/CRUDTestCase.java in
> sca/itest/samples/implementation-crud.
> This "wrapper" JUnit test case is as follows:
>
> package crud;
>
> import junit.framework.TestCase;
>
> public class CRUDTestCase extends TestCase {
>
> public void test() throws Exception {
> CRUDClient.main(null);
> }
> }
> 5. That's all! sca/itest/samples/implementation-crud gets the
> crud.CRUDClient class from <testResources> and all the extension
> implementation classes from the sample-implementation-crud
> dependency. There's no need to add any src/test classes to the
> jar file.
>
> I have created TUSCANY-1264 for this change and I have attached a
> patch to convert the simple-bigbank and implementation-crud samples.
> These samples and itests build and run with maven but I haven't built
> a new distribution to verify that the sample ant scripts still work.
>
> Simon
>
> Simon Laws wrote:
>
>>>
>>>
>>> I've checked in changes to allows the provided jar to be run (and
>>> built).
>>
>>
>> Outstanding is the issue of including classes from
>> src/test in the sample jar or alternatively moving the application
>> classes
>> to src/main. This effect of this currently is that
>>
>> binding.echo
>> databinding.echo
>> implementation.crud
>>
>> Don't work out of the box with
>>
>> ant
>>
>> You have to do
>>
>> ant compile
>> ant
>>
>> If we don't want to ship junit in the binary distribution we should move
>> them. The binary distribution ships the src for the Junit tests b.t.w. so
>> I'm going to take a quick look at why maven isn't packaging the classes.
>>
>> 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: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I was able to solve this problem using the "wrapping" approach
without needing to add any src/test code to the jar file. I did
the following to convert implementation-crud:
1. Created an implementation-crud module under sca/itest/samples.
2. Created a pom for this module that uses <testResources> to copy
the contents of samples/implementation-crud/target/test-classes.
3. Removed src/test/CRUDTestCase.java from samples/implementation-crud.
4. Created src/test/crud/CRUDTestCase.java in sca/itest/samples/implementation-crud.
This "wrapper" JUnit test case is as follows:
package crud;
import junit.framework.TestCase;
public class CRUDTestCase extends TestCase {
public void test() throws Exception {
CRUDClient.main(null);
}
}
5. That's all! sca/itest/samples/implementation-crud gets the
crud.CRUDClient class from <testResources> and all the extension
implementation classes from the sample-implementation-crud
dependency. There's no need to add any src/test classes to the
jar file.
I have created TUSCANY-1264 for this change and I have attached a
patch to convert the simple-bigbank and implementation-crud samples.
These samples and itests build and run with maven but I haven't built
a new distribution to verify that the sample ant scripts still work.
Simon
Simon Laws wrote:
>>
>>
>> I've checked in changes to allows the provided jar to be run (and built).
>
> Outstanding is the issue of including classes from
> src/test in the sample jar or alternatively moving the application classes
> to src/main. This effect of this currently is that
>
> binding.echo
> databinding.echo
> implementation.crud
>
> Don't work out of the box with
>
> ant
>
> You have to do
>
> ant compile
> ant
>
> If we don't want to ship junit in the binary distribution we should move
> them. The binary distribution ships the src for the Junit tests b.t.w. so
> I'm going to take a quick look at why maven isn't packaging the classes.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
>
>
> I've checked in changes to allows the provided jar to be run (and built).
Outstanding is the issue of including classes from
src/test in the sample jar or alternatively moving the application classes
to src/main. This effect of this currently is that
binding.echo
databinding.echo
implementation.crud
Don't work out of the box with
ant
You have to do
ant compile
ant
If we don't want to ship junit in the binary distribution we should move
them. The binary distribution ships the src for the Junit tests b.t.w. so
I'm going to take a quick look at why maven isn't packaging the classes.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I got this to work for the simple-bigbank sample. It was much less
painful than I expected. Here's what I did:
1. Created a samples directory under sca/itest.
2. Created a simple-bigbank directory under sca/itest/samples.
3. Created poms for both of the above.
4. Removed the src/test files from samples/simple-bigbank.
5. Created src/test/bigbank/BigBankTestCase.java in sca/itest/samples/simple-bigbank.
This "wrapper" JUnit test case is extremely simple:
package bigbank;
import bigbank.client.BigBankClient;
import junit.framework.TestCase;
public class BigBankTestCase extends TestCase {
public void test() throws Exception {
BigBankClient.main(null);
}
}
6. That's all! The pom for sca/itest/samples/simple-bigbank
contains sample-simple-bigbank as a dependency, so the jar
file for this is picked up from my local maven repo.
I'll try another sample, then raise a JIRA and post a complete patch
for the changes.
Simon
Simon Nash wrote:
> I am wondering if we could get the best of both worlds by having
> JUnit tests under sca/itest that invoke the samples (think of these
> tests as "wrappers"), and removing all traces of JUnit from the
> samples themselves. I'll try to do this on one or two samples and
> see how well this works out.
>
> Simon
>
> Simon Laws wrote:
>
>> snip
>>
>>>
>>> I don't think the client that is used should be different
>>> depending on whether ant or mvn was used to run the sample.
>>> In both cases I think calculatorClient should be used.
>>>
>>
>> So we would need to engineer the poms in the build to run the new client
>> classes rather than the junit classes. I don't think we should take the
>> junit tests out of the samples for the main build as the samples
>> provide a
>> useful extra set of tests (although if we have to to make for a better
>> user
>> experience then we have to). I'm just going to look at how the
>> distribution
>> build works. Maybe we can ship a different pom for the samples. If
>> someone
>> knows let us know.
>>
>> Simon
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I am wondering if we could get the best of both worlds by having
JUnit tests under sca/itest that invoke the samples (think of these
tests as "wrappers"), and removing all traces of JUnit from the
samples themselves. I'll try to do this on one or two samples and
see how well this works out.
Simon
Simon Laws wrote:
> snip
>
>>
>> I don't think the client that is used should be different
>> depending on whether ant or mvn was used to run the sample.
>> In both cases I think calculatorClient should be used.
>>
>
> So we would need to engineer the poms in the build to run the new client
> classes rather than the junit classes. I don't think we should take the
> junit tests out of the samples for the main build as the samples provide a
> useful extra set of tests (although if we have to to make for a better user
> experience then we have to). I'm just going to look at how the distribution
> build works. Maybe we can ship a different pom for the samples. If someone
> knows let us know.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
snip
>
> I don't think the client that is used should be different
> depending on whether ant or mvn was used to run the sample.
> In both cases I think calculatorClient should be used.
>
So we would need to engineer the poms in the build to run the new client
classes rather than the junit classes. I don't think we should take the
junit tests out of the samples for the main build as the samples provide a
useful extra set of tests (although if we have to to make for a better user
experience then we have to). I'm just going to look at how the distribution
build works. Maybe we can ship a different pom for the samples. If someone
knows let us know.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I haven't yet had time to look at all the sample code. Looking
at the calculator sample, running it with ant uses calculatorClient
from src/main and running it with mvn uses calculatorTestCase from
src/test. I don't think the client that is used should be different
depending on whether ant or mvn was used to run the sample.
In both cases I think calculatorClient should be used.
Simon
Simon Laws wrote:
> On 5/10/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>
>> I'm just catching up with this thread.... and these comments
>> are "shooting from the hip" as I haven't had time to look at
>> the sample code in the distributions yet.
>>
>> I don't think samples should use JUnit. Samples should show
>> how a user would build a (very simple) real application.
>> Samples are not the same as tests.
>>
>> I don't see the need to have both class and jar executables
>> for every sample. Perhaps there could be a mixture of these
>> styles to show both options. I will look at the distribution
>> contents and come back with a more considered opinion on this.
>>
>> Simon
>>
>> ant elder wrote:
>>
>> > On 5/10/07, Simon Laws <si...@googlemail.com> wrote:
>> >
>> > <snip/>
>> >
>> > B.t.w the binary distro includes bigbank, das-service and
>> loan-application
>> >
>> >> none of which are in the build currently. We should either fix them or
>> >> remove them.
>> >
>> >
>> >
>> > Thanks, I've excluded those now.
>> >
>> > ...ant
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> As we have decided to forgo Junit this time round should I move the
>> client
>
> classes out of the /src/test and into /src/main? Clients only appear in
> /src/test in the three cases where we are showing how to build an extension
> (as building the client is not an intrinsic part of building the
> extension).
> However if the Junit tests, and hence the non-junit (but none the less
> test)
> client, are not included in the sample jars shipped with the distribution
> then the ant scripts won't work.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
On 5/10/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I'm just catching up with this thread.... and these comments
> are "shooting from the hip" as I haven't had time to look at
> the sample code in the distributions yet.
>
> I don't think samples should use JUnit. Samples should show
> how a user would build a (very simple) real application.
> Samples are not the same as tests.
>
> I don't see the need to have both class and jar executables
> for every sample. Perhaps there could be a mixture of these
> styles to show both options. I will look at the distribution
> contents and come back with a more considered opinion on this.
>
> Simon
>
> ant elder wrote:
>
> > On 5/10/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > <snip/>
> >
> > B.t.w the binary distro includes bigbank, das-service and
> loan-application
> >
> >> none of which are in the build currently. We should either fix them or
> >> remove them.
> >
> >
> >
> > Thanks, I've excluded those now.
> >
> > ...ant
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> As we have decided to forgo Junit this time round should I move the client
classes out of the /src/test and into /src/main? Clients only appear in
/src/test in the three cases where we are showing how to build an extension
(as building the client is not an intrinsic part of building the extension).
However if the Junit tests, and hence the non-junit (but none the less test)
client, are not included in the sample jars shipped with the distribution
then the ant scripts won't work.
Simon
Re: Sample READMEs and ant builds
Posted by Simon Nash <na...@hursley.ibm.com>.
I'm just catching up with this thread.... and these comments
are "shooting from the hip" as I haven't had time to look at
the sample code in the distributions yet.
I don't think samples should use JUnit. Samples should show
how a user would build a (very simple) real application.
Samples are not the same as tests.
I don't see the need to have both class and jar executables
for every sample. Perhaps there could be a mixture of these
styles to show both options. I will look at the distribution
contents and come back with a more considered opinion on this.
Simon
ant elder wrote:
> On 5/10/07, Simon Laws <si...@googlemail.com> wrote:
>
> <snip/>
>
> B.t.w the binary distro includes bigbank, das-service and loan-application
>
>> none of which are in the build currently. We should either fix them or
>> remove them.
>
>
>
> Thanks, I've excluded those now.
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
On 5/10/07, Simon Laws <si...@googlemail.com> wrote:
<snip/>
B.t.w the binary distro includes bigbank, das-service and loan-application
> none of which are in the build currently. We should either fix them or
> remove them.
Thanks, I've excluded those now.
...ant
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
Ok, The scripts already take account of the missing JUnit so let's not
change that just yet.
Happy to go add the Java -cp run line to the READMEs and the jar command to
the build.xml. I have a NPE in the WS tests when run from the command line I
have to fix first.
B.t.w the binary distro includes bigbank, das-service and loan-application
none of which are in the build currently. We should either fix them or
remove them.
Simon
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
On 5/10/07, Simon Laws <si...@googlemail.com> wrote:
>
> +1 to including "java -cp" instructions. The samples/README (to which the
> reader is referred) contains this already. Do you want it included in
> individual READMEs too?
I think so yes as it seems like it makes things easier for people the very
first time - unzip the binary distro, open the calculator readme and right
at the top it has the "java -cp..." you can cutNpaste and it just works. No
reading lots of text or messing about having to build things.
I'm not sure I really like distributing sample jars. But it is fairly easy
> to make the jars and give people the option of how they want to run the
> sample
>
> java -cp -jar
> java -cp class
>
> So if people like the jar approach we can easily add the jar line into the
> ant files.
I like this approach :) and as the binary distro is already including the
sample jars i think we might as well. We could evaluate how it works and if
it less than ideal we could change this before the 1.0 release
As an aside. JUnit isn't currently shipped with the binary distro which
> means I have to specialise the ant scrips in a couple of places to stop it
> trying to build junit test cases (this is because I have put the client
> code
> for binding, databinding and implementation samples in the test package to
> separate it from what is intended to be an example implementation). If we
> ship junit I could potentially generalize the scripts.
It would be easy enough to add junit to the binary distro and to add the
junit CPL license to the LICENSE and NOTICE files. I guess it depends how
much of an improvement it makes to the build scripts, I don't have an
opinion either way. I would like to try to cut a distro in an hour or two
though...:)
Simon
>
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
+1 to including "java -cp" instructions. The samples/README (to which the
reader is referred) contains this already. Do you want it included in
individual READMEs too?
I'm not sure I really like distributing sample jars. But it is fairly easy
to make the jars and give people the option of how they want to run the
sample
java -cp -jar
java -cp class
So if people like the jar approach we can easily add the jar line into the
ant files.
As an aside. JUnit isn't currently shipped with the binary distro which
means I have to specialise the ant scrips in a couple of places to stop it
trying to build junit test cases (this is because I have put the client code
for binding, databinding and implementation samples in the test package to
separate it from what is intended to be an example implementation). If we
ship junit I could potentially generalize the scripts.
Simon
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
I've started doing one of these now. One thing is should the READMEs say how
to run the sample's from the cmd line with "java -cp..."? We distribute the
sample jar's with the binary distro to make it really easy to run the
samples without having to do any building at all with Ant or mvn, but
there's not so much point to that if we don't document it.
Another thing I wondered about was if we do document the "java -cp..." way
of running the samples then do the And builds need to create a jar for the
sample like the mvn build does?
...ant
On 5/8/07, ant elder <an...@gmail.com> wrote:
>
> Ok, i'll do at least one to help review how its done, i'll start at the
> bottom with the supplychain sample.
>
> ...ant
>
> On 5/8/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > Hi
> >
> > I'm working steadily through the samples...
> >
> > - Converting readmes to simple text READMEs and updating where
> > appropriate
> > - Adding build.xml (or mulitple as required) to provide an ant build for
> > the
> > binary distribution
> > - Adding a diagram of the sample composite (not necessary for the
> > distribution but I always do this for myself as a way of working out
> > what's
> > going on)
> >
> > Anyhow. I'm down to calculator-script as I write this. So if anyone
> > want's
> > to take a look at how its working out and provide feedback that would be
> > good. If anyone wants to do a few that would be even better ;-)
> >
> > Regards
> >
> > Simon
> >
>
>
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
The Axis2 binding is still broken and therefor also the binary distribution.
I hope to get them up and running again this morning.
...ant
On 5/9/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 5/9/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > How am I supposed to run the sample ant builds ? Here are the steps I
> did
> > :
> >
> > 1.build the distributions
> > 2.unzip the distributions to a temporary directory
> > 3.go to inside the distributions sample/calculator directory (either
> > binary/source)
> > 4.issue an "ant" command
> >
> >
> > run:
> > [java] Exception in thread "main" java.lang.NoClassDefFoundError:
> > org/apache/tuscany/assembly/impl/DefaultAssemblyFactory
> > [java] at
> > org.apache.tuscany.binding.axis2.Axis2ModuleActivator.start(
> > Axis2ModuleActivator.java:48)
> > [java] at
> > org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.startModules(
> > ReallySmallRuntime.java:146)
> > [java] at
> > org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.start(
> > ReallySmallRuntime.java:101)
> > [java] at
> > org.apache.tuscany.host.embedded.impl.DefaultSCADomain.<init>(
> > DefaultSCADomain.java:86)
> > [java] at
> > org.apache.tuscany.host.embedded.SCADomain.createNewInstance(
> > SCADomain.java:186)
> > [java] at
> > org.apache.tuscany.host.embedded.SCADomain.newInstance(SCADomain.java
> :52)
> > [java] at calculator.CalculatorClient.main(
> CalculatorClient.java
> > :31)
> > [java] Java Result: 1
> >
> > If I try on the source distribution, I get the following :
> >
> > compile:
> > [javac] Compiling 11 source files to
> > D:\temp\M3\tuscany-
> > sca-1.0-incubating-SNAPSHOT-src\samples\calculator\target\classes
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:22:
> > package org.apache.tuscany.host
> > embedded does not exist
> > [javac] import org.apache.tuscany.host.embedded.SCADomain;
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:21:
> > package org.osoa.sca.annot
> > tions does not exist
> > [javac] import org.osoa.sca.annotations.Reference;
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:34:
> > cannot find symbol
> > [javac] symbol : class Reference
> > [javac] location: class calculator.CalculatorServiceImpl
> > [javac] @Reference
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:39:
> > cannot find symbol
> > [javac] symbol : class Reference
> > [javac] location: class calculator.CalculatorServiceImpl
> > [javac] @Reference
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:44:
> > cannot find symbol
> > [javac] symbol : class Reference
> > [javac] location: class calculator.CalculatorServiceImpl
> > [javac] @Reference
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:49:
> > cannot find symbol
> > [javac] symbol : class Reference
> > [javac] location: class calculator.CalculatorServiceImpl
> > [javac] @Reference
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
> > cannot find symbol
> > [javac] symbol : class SCADomain
> > [javac] location: class calculator.CalculatorClient
> > [javac] SCADomain domain =
> > SCADomain.newInstance("http://calc", ".", "Calculator.composite");
> > [javac] ^
> > [javac] D:\temp\M3\tuscany-
> >
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
> > cannot find symbol
> > [javac] symbol : variable SCADomain
> > [javac] location: class calculator.CalculatorClient
> > [javac] SCADomain domain =
> > SCADomain.newInstance("http://calc", ".", "Calculator.composite");
> > [javac] ^
> > [javac] 8 errors
> >
> > BUILD FAILED
> > D:\temp\M3\tuscany-
> > sca-1.0-incubating-SNAPSHOT-src\samples\calculator\build.xml:31:
> > Compile failed; see the compiler error output for details.
> >
> > Total time: 1 second
> >
> > On 5/8/07, ant elder <an...@gmail.com> wrote:
> > > Ok, i'll do at least one to help review how its done, i'll start at
> the
> > > bottom with the supplychain sample.
> > >
> > > ...ant
> > >
> > > On 5/8/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > Hi
> > > >
> > > > I'm working steadily through the samples...
> > > >
> > > > - Converting readmes to simple text READMEs and updating where
> > appropriate
> > > > - Adding build.xml (or mulitple as required) to provide an ant build
> > for
> > > > the
> > > > binary distribution
> > > > - Adding a diagram of the sample composite (not necessary for the
> > > > distribution but I always do this for myself as a way of working out
> > > > what's
> > > > going on)
> > > >
> > > > Anyhow. I'm down to calculator-script as I write this. So if anyone
> > want's
> > > > to take a look at how its working out and provide feedback that
> would
> > be
> > > > good. If anyone wants to do a few that would be even better ;-)
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Hi Luciano
>
> The ant scripts will only work in the binary distribution because they
> rely
> on the tuscany-sca-all-1.0-incubating-SNAPSHOT.jar which is not available
> in
> the src distribution.
>
> The error you are getting in the binary distribution looks like it is to
> do
> with problems in the axis2 binding. I have just been through the process
> getting the latest head from svn, building a binary distribution, upacking
> it and running ant on the calculator sample. It works for me but then I am
> not including binding-ws-axis2 in my disitribution.
>
> The HelloWorld web service sample fails for me during the main mvn build
> so
> I guess the axis2 binding is still broken in some way.
>
> Regards
>
> Simon
>
Re: Sample READMEs and ant builds
Posted by Simon Laws <si...@googlemail.com>.
On 5/9/07, Luciano Resende <lu...@gmail.com> wrote:
>
> How am I supposed to run the sample ant builds ? Here are the steps I did
> :
>
> 1.build the distributions
> 2.unzip the distributions to a temporary directory
> 3.go to inside the distributions sample/calculator directory (either
> binary/source)
> 4.issue an "ant" command
>
>
> run:
> [java] Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/tuscany/assembly/impl/DefaultAssemblyFactory
> [java] at
> org.apache.tuscany.binding.axis2.Axis2ModuleActivator.start(
> Axis2ModuleActivator.java:48)
> [java] at
> org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.startModules(
> ReallySmallRuntime.java:146)
> [java] at
> org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.start(
> ReallySmallRuntime.java:101)
> [java] at
> org.apache.tuscany.host.embedded.impl.DefaultSCADomain.<init>(
> DefaultSCADomain.java:86)
> [java] at
> org.apache.tuscany.host.embedded.SCADomain.createNewInstance(
> SCADomain.java:186)
> [java] at
> org.apache.tuscany.host.embedded.SCADomain.newInstance(SCADomain.java:52)
> [java] at calculator.CalculatorClient.main(CalculatorClient.java
> :31)
> [java] Java Result: 1
>
> If I try on the source distribution, I get the following :
>
> compile:
> [javac] Compiling 11 source files to
> D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\target\classes
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:22:
> package org.apache.tuscany.host
> embedded does not exist
> [javac] import org.apache.tuscany.host.embedded.SCADomain;
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:21:
> package org.osoa.sca.annot
> tions does not exist
> [javac] import org.osoa.sca.annotations.Reference;
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:34:
> cannot find symbol
> [javac] symbol : class Reference
> [javac] location: class calculator.CalculatorServiceImpl
> [javac] @Reference
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:39:
> cannot find symbol
> [javac] symbol : class Reference
> [javac] location: class calculator.CalculatorServiceImpl
> [javac] @Reference
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:44:
> cannot find symbol
> [javac] symbol : class Reference
> [javac] location: class calculator.CalculatorServiceImpl
> [javac] @Reference
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:49:
> cannot find symbol
> [javac] symbol : class Reference
> [javac] location: class calculator.CalculatorServiceImpl
> [javac] @Reference
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
> cannot find symbol
> [javac] symbol : class SCADomain
> [javac] location: class calculator.CalculatorClient
> [javac] SCADomain domain =
> SCADomain.newInstance("http://calc", ".", "Calculator.composite");
> [javac] ^
> [javac] D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
> cannot find symbol
> [javac] symbol : variable SCADomain
> [javac] location: class calculator.CalculatorClient
> [javac] SCADomain domain =
> SCADomain.newInstance("http://calc", ".", "Calculator.composite");
> [javac] ^
> [javac] 8 errors
>
> BUILD FAILED
> D:\temp\M3\tuscany-
> sca-1.0-incubating-SNAPSHOT-src\samples\calculator\build.xml:31:
> Compile failed; see the compiler error output for details.
>
> Total time: 1 second
>
> On 5/8/07, ant elder <an...@gmail.com> wrote:
> > Ok, i'll do at least one to help review how its done, i'll start at the
> > bottom with the supplychain sample.
> >
> > ...ant
> >
> > On 5/8/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > Hi
> > >
> > > I'm working steadily through the samples...
> > >
> > > - Converting readmes to simple text READMEs and updating where
> appropriate
> > > - Adding build.xml (or mulitple as required) to provide an ant build
> for
> > > the
> > > binary distribution
> > > - Adding a diagram of the sample composite (not necessary for the
> > > distribution but I always do this for myself as a way of working out
> > > what's
> > > going on)
> > >
> > > Anyhow. I'm down to calculator-script as I write this. So if anyone
> want's
> > > to take a look at how its working out and provide feedback that would
> be
> > > good. If anyone wants to do a few that would be even better ;-)
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hi Luciano
The ant scripts will only work in the binary distribution because they rely
on the tuscany-sca-all-1.0-incubating-SNAPSHOT.jar which is not available in
the src distribution.
The error you are getting in the binary distribution looks like it is to do
with problems in the axis2 binding. I have just been through the process
getting the latest head from svn, building a binary distribution, upacking
it and running ant on the calculator sample. It works for me but then I am
not including binding-ws-axis2 in my disitribution.
The HelloWorld web service sample fails for me during the main mvn build so
I guess the axis2 binding is still broken in some way.
Regards
Simon
Re: Sample READMEs and ant builds
Posted by Luciano Resende <lu...@gmail.com>.
How am I supposed to run the sample ant builds ? Here are the steps I did :
1.build the distributions
2.unzip the distributions to a temporary directory
3.go to inside the distributions sample/calculator directory (either
binary/source)
4.issue an "ant" command
run:
[java] Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/tuscany/assembly/impl/DefaultAssemblyFactory
[java] at
org.apache.tuscany.binding.axis2.Axis2ModuleActivator.start(Axis2ModuleActivator.java:48)
[java] at
org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:146)
[java] at
org.apache.tuscany.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:101)
[java] at
org.apache.tuscany.host.embedded.impl.DefaultSCADomain.<init>(DefaultSCADomain.java:86)
[java] at
org.apache.tuscany.host.embedded.SCADomain.createNewInstance(SCADomain.java:186)
[java] at
org.apache.tuscany.host.embedded.SCADomain.newInstance(SCADomain.java:52)
[java] at calculator.CalculatorClient.main(CalculatorClient.java:31)
[java] Java Result: 1
If I try on the source distribution, I get the following :
compile:
[javac] Compiling 11 source files to
D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\target\classes
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:22:
package org.apache.tuscany.host
embedded does not exist
[javac] import org.apache.tuscany.host.embedded.SCADomain;
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:21:
package org.osoa.sca.annot
tions does not exist
[javac] import org.osoa.sca.annotations.Reference;
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:34:
cannot find symbol
[javac] symbol : class Reference
[javac] location: class calculator.CalculatorServiceImpl
[javac] @Reference
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:39:
cannot find symbol
[javac] symbol : class Reference
[javac] location: class calculator.CalculatorServiceImpl
[javac] @Reference
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:44:
cannot find symbol
[javac] symbol : class Reference
[javac] location: class calculator.CalculatorServiceImpl
[javac] @Reference
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorServiceImpl.java:49:
cannot find symbol
[javac] symbol : class Reference
[javac] location: class calculator.CalculatorServiceImpl
[javac] @Reference
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
cannot find symbol
[javac] symbol : class SCADomain
[javac] location: class calculator.CalculatorClient
[javac] SCADomain domain =
SCADomain.newInstance("http://calc", ".", "Calculator.composite");
[javac] ^
[javac] D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\src\main\java\calculator\CalculatorClient.java:31:
cannot find symbol
[javac] symbol : variable SCADomain
[javac] location: class calculator.CalculatorClient
[javac] SCADomain domain =
SCADomain.newInstance("http://calc", ".", "Calculator.composite");
[javac] ^
[javac] 8 errors
BUILD FAILED
D:\temp\M3\tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\calculator\build.xml:31:
Compile failed; see the compiler error output for details.
Total time: 1 second
On 5/8/07, ant elder <an...@gmail.com> wrote:
> Ok, i'll do at least one to help review how its done, i'll start at the
> bottom with the supplychain sample.
>
> ...ant
>
> On 5/8/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > Hi
> >
> > I'm working steadily through the samples...
> >
> > - Converting readmes to simple text READMEs and updating where appropriate
> > - Adding build.xml (or mulitple as required) to provide an ant build for
> > the
> > binary distribution
> > - Adding a diagram of the sample composite (not necessary for the
> > distribution but I always do this for myself as a way of working out
> > what's
> > going on)
> >
> > Anyhow. I'm down to calculator-script as I write this. So if anyone want's
> > to take a look at how its working out and provide feedback that would be
> > good. If anyone wants to do a few that would be even better ;-)
> >
> > Regards
> >
> > Simon
> >
>
--
Luciano Resende
http://people.apache.org/~lresende
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Sample READMEs and ant builds
Posted by ant elder <an...@gmail.com>.
Ok, i'll do at least one to help review how its done, i'll start at the
bottom with the supplychain sample.
...ant
On 5/8/07, Simon Laws <si...@googlemail.com> wrote:
>
> Hi
>
> I'm working steadily through the samples...
>
> - Converting readmes to simple text READMEs and updating where appropriate
> - Adding build.xml (or mulitple as required) to provide an ant build for
> the
> binary distribution
> - Adding a diagram of the sample composite (not necessary for the
> distribution but I always do this for myself as a way of working out
> what's
> going on)
>
> Anyhow. I'm down to calculator-script as I write this. So if anyone want's
> to take a look at how its working out and provide feedback that would be
> good. If anyone wants to do a few that would be even better ;-)
>
> Regards
>
> Simon
>