I think organizing the samples like this is a good idea. I'd suggest
going one step further and place each sample with the implementation
of the service that it is illustrating. That way it becomes much
easier to tag/release each module on its own.
Also, the samples that are in "java" and "echo" need the "standalone"
installation to run so how about grouping them with that?
The web-app based ones ("webapp" and potentially "bigbank") don't
need the user to download/install the standalone installation at all
and we could package those as a separate unit as well.
--
Jeremy
On Oct 5, 2006, at 5:04 AM, ant elder wrote:
There was a discussion on the samples a while back [1] where i
think there
was some agreement to restructure the samples based on the
extension they
are demonstrating. It wasn't so clear what the out come of that
discussion
was so how about the following (for now ignoring whats in/out/works/
broken):
sampleapps/bigbank
bigbank
samples/echo
- echo.binding
- echo.databinding
samples/javascript
helloworld
samples/axis2
helloworldws
helloworldwsclient
helloworldwsclientOM
helloworldwsOM
samples/celtix
helloworldws-celtix
samples/spring
spring.simple
spring
samples/rmi
helloworld.rmiReference
helloworld.rmiService
samples/jsonrpc
helloworldjsonrpc
samples/java?
calculator
eagerinit
inner.composite
local.wire
local.wire.cdi
simplecallback
supplychain
webapp
In the same thread there was the suggestion about using a
calculator sample
instead of or as well as helloworld so I'll also add a javascript
calculator
sample and look at doing both for the other script languages as well.
If we can reach some consensus about what this should look like I
can do the
changes.
...ant
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg06572.html
On 10/4/06, Simon Nash <[EMAIL PROTECTED]> wrote:
I'm planning to go through all the SCA Java samples, building them
and runnning them, to make sure that they work. We also need to
consider whether this is the right set of samples to introduce
users to the capabilities of SCA and Tuscany.
Right now we have the following in the samples/sca directory.
Samples that are currently building:
bigbank
calculator
eagerinit
echo.binding
echo.databinding
helloworldJavaScript
helloworldws
helloworldws-celtix
helloworldwsclient
local.wire
local.wire.cdi
spring.simple
supplychain
webapp
Samples that are not currently building:
helloworld.rmiReference
helloworld.rmiService
helloworldjsonrpc
helloworldwsclientOM
helloworldwsOM
inner.composite
simplecallback
spring
For a first pass I would assume that we are intending to deliver the
former list in our M2 binary release but not the latter. Is this
a correct assumption? Should any of the "not building" samples be
included? Should any of the "building" samples be excluded?
Should we be adding any more samples that are currently not in
either list?
From a quick look through these lists, I have the following
questions.
1. It is my understanding that we are including RMI, so presumably
we need the RMI samples.
2. It is my understanding that we are not including celtix in the
binary release, so presumably we don't need the celtix sample.
3. I don't know whether we will be including Spring, so I'm not
whether we will need the spring.simple sample.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
