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
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
On 5/16/07, Simon Nash [EMAIL PROTECTED] 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
On 5/16/07, Simon Laws [EMAIL PROTECTED] wrote:
On 5/16/07, Simon Nash [EMAIL PROTECTED] 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
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
Comments inline.
Simon
Simon Laws wrote:
On 5/16/07, Simon Laws [EMAIL PROTECTED] wrote:
On 5/16/07, Simon Nash [EMAIL PROTECTED] 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
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
No go ahead - I'm testing the other samples at the moment.
Simon
I think we may be close to reaching an agreement here :-) See
my response to SimonL's suggestion below.
Simon
Simon Laws wrote:
On 5/13/07, Simon Nash [EMAIL PROTECTED] wrote:
Simon Laws wrote:
So let me try and summarize...
All samples will be:
samples/
src/
main/
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
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
On 5/13/07, Simon Nash [EMAIL PROTECTED] wrote:
Simon Laws wrote:
So let me try and summarize...
All samples will be:
samples/
src/
main/
sample code
client code (non-junit)
test/
junit tests
Does this mean that client code would become part of the
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
On 5/14/07, Simon Laws [EMAIL PROTECTED] 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
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.
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
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 -
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
On 5/11/07, Simon Laws [EMAIL PROTECTED] 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
ant elder wrote:
On 5/11/07, Simon Laws [EMAIL PROTECTED] 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
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
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
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
[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
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
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/
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
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
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)
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
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
+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
On 5/10/07, Simon Laws [EMAIL PROTECTED] 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
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
On 5/10/07, Simon Laws [EMAIL PROTECTED] 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
On 5/10/07, Simon Nash [EMAIL PROTECTED] 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
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
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
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
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.
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
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
On 5/9/07, Luciano Resende [EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] wrote:
On 5/9/07, Luciano Resende [EMAIL PROTECTED] wrote:
How am I supposed to run the sample 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
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 [EMAIL PROTECTED] wrote:
Hi
I'm working steadily through the samples...
- Converting readmes to simple text READMEs and updating where appropriate
-
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
47 matches
Mail list logo
