ant elder wrote: > Here are some specific ideas to kick around: > > 1) how about calling business samples 'demos' and technology samples just > 'samples' > > 2) restructure the current samples folder to be something like: > samples > - demos > - bigbank > - petstore > - ... > - das > - ... > - sdo > - ... > - sca > - bindings > - jsonrpc > - ws > - ... > - componentTypes > - java > - javascript > - ... > > 3) There should be a consistent set of samples within bindings, > componentTypes etc so its easy to copy things to create new samples and add > new function > > 4) samples are like functional tests so we should add a sample for every bit > of existing and new function > > 5) Fix the testing/tomcat stuff so all the samples doing functional testing > get run as part of a regular build Many of the samples require tomcat and despite the the mock functional testing I still believe we'll see these samples/demos break. So by this proposal are we going to remove the end user aspect that these tests did? Testing as close to a user environment as possible and still remain automated? If the answer is to remove then will we be doing this manually? > > In more detail: > > Right now we have a samples folder which has things like the bigbank, > helloworld, javascript and various other stuff in it. The bigbank sample > shows a complete SCA application that does something useful and real world > like, the helloworld samples on the other hand are very simplistic and > really just help a developer getting started with SCA. I think Bigbank fits > into what you describe as business samples and the helloworld samples are > technology samples, but to make this clearer how about calling business > samples 'demos' and technology samples just 'samples'? > > Samples to me could be a lot like functional tests, for every bit of new > function we add we should add a sample showing how to use it. Samples would > show just one bit of function so its obvious whats required without getting > confused by unrelated code and xml. I've started trying to use this approach > for the JavaScript samples: > http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/JavaScript/ > > If we go that way it has to be really easy to create a new sample, the > helloworld samples aren't so easy to copy but after a few different attempts > with the JavaScript ones its now relatively easy to just copy an existing > JavaScript sample to a new project and do a global edit to change the sample > number. Just so I understand can you please elaborate on what was changed that made the Javascript examples so much easier to copy and reuses over the helloworld.. Thanks.
> The most difficult part is updating the readme.htm file with all the > ascii art directory structure pictures etc, I think its probably better to > use plain txt readme files with simple content for samples and only have > fancy html readme's for the demos (and gif's instead of ascii art?). Creating gifs and maintaining them seems more difficult the ascii art and there is no mandate that any particular samples have that. I didn't see this as an issue. The ideas was to get the use familiar with samples layout. I thought this was good for some of the first samples that show where your sca files are located etc. There is no requirement that every "sample" do that. > Another > minor problem with the JavaScript ones is the name is javascript-sampleX but > it may be better to have sample-javascriptX so then all samples would get > grouped together in your IDE. I think java helloworld are grouped. > > Another aspect is it should be easy and obvious what samples are required > when creating something new like a new componentType. Most componentTypes > are going to require similar samples like a helloworld component, injecting > properties and references, initialization and scoping etc. If we get a good > set of these for the Java componentType then when creating a new > componentType you can just copy all the Java ones and update as required and > its obvious what needs to get done. That's one of the reasons helloworld samples are there for. > This probably all also applies for > bindings and maybe theres a set of samples required for Tuscany core > function as well (showing module fragments, subsystmes etc?). This way we'd > also end up with a consistent set of samples, so if you've learnt how to use > one componentType then picking up a new one the samples would be familiar. > This would also all work across the different language impls so Java, C++, > and PHP SCA impls could all have a similar set of samples. > > Right now some of the binding functional testing is done with existing > samples but these don't actually get run as part of the main build so they > do get broken. If the functional testing is going to be done in samples then > we need to sort out the testing/tomcat stuff so its easy to do and so the > samples get properly run as part of the regular build process. Not sure where to go here. I see both sides people don't want to run that with every build. Ideally it would all run in a nightly build. I haven't had much luck with getting that in place. The apache infrastructure "GUMP' doesn't seem to support maven 2.0 builds. > > I think samples should expand on each other, for example they'd be a basic > helloworld componentType sample, then a WS entryPoint sample exposes > helloworld as a WS, then a WS-Security sample secures the WS entryPoint > sample. Once again I think I see that in helloword. And from the the main readme if you follow down you'll basically get that there is a plain J2see. There are some axis samples that were there to show integration with a plain axis client/service at one time that was considered important. There is a sample using helloworld as in a web application ... we once deemed that as important to show too. There is a helloworld showing using an entrypoint and an externalservice. > I think Demo's on the other hand should be complete and self > contained applications. There could be tutorials that show how each demo was > developed. Basically I agree. Bigbank does have a tutorial it's under documentation "SCA: "Building your first application" And yes the main readme and a readme in the the directory of bigbank should point or this tutorial Or should it be actually be relocated to the demo? Also it may be slightly out of date since it was first written some things in the technology has changed. > > For the demos, we already have bigbank so we might as well keep it but it > needs to be made more obvious what it does and how to use it. Right now I > can't find any readme's or doc describing it, there used to be a pdf about > it, where's that gone (and from what I remember that was like a 40 page doc > which is way more than most people will have time to read)? Yes it is long. But if you want the details ? > Someone > mentioned petstore and I think that could be a worthwhile demo as well - its > so well known so people can grok whats going on without needing to read a 40 > page document. I think I heard that the PHP SCA impl have their own demo app > which isn't bigbank, it may be worth looking at what they have and also > adding it as a demo for the Java impl. Petstore, PHP Flashy demos etc Will some people may become confused with all the samples and demos? Assuming all the resources to do all this will people need a 40 page document for a roadmap of the demos and samples? > I think the demo documentation needs > to make clearer why SCA is a good thing, its not real obvious right now from > the existing doc why this is better than using something like J2EE or just > wiring up a bunch of POJOs with Spring. OK lets find out what that is and either incorporate into bigbank or get rid of bigbank for something that does this better. > > It would be good to have some more cool technology demo's, but right now the > only function Tuscany supports is fairly mainstream. I think the E4X support > in JavaScript could make some interesting WS mediation samples, but the > function isn't quite there yet. The json-rpc/ajax stuff could be really cool > but its also not ready yet. Maybe as this first milestone release is > targeting getting new contributors rather than business users then just > sorting out the functional samples and cleaning up the bigbank demo would be > enough. > ...ant Personally I'm not for cool and flashy here in OS. Let give reason for why this technology is needed and how to use it. Let's not drape flash(cool) over it for the sake of "FLASH" or that we can't really show the latter. > > On 4/12/06, haleh mahbod < [EMAIL PROTECTED]> wrote: >> Hi, >> >> >> What are the categories of samples that we need to consider for Tuscany? >> >> I see two potential categories. >> >> >> >> 1) Business samples - Focused on showing how Tuscany solves certain >> business >> problems. >> >> 2) Technology samples - Focused on showing developers how to use >> Tuscanyfeatures such as Transaction. >> >> >> >> Does this look right? >> >> >> >> If yes, what are some good samples that we can consider for each category? >> >> >> >> >> What should our approach to Samples be? Start with one sample and expand >> it >> to show additional functionality; or >> >> create distinct samples? >> >> >> >> Haleh >> >> > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
