Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level.
For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > Hi, > > I'd prefer to have business samples under 'samples' itself. I > perceive that > technology samples will go to the respective project directories > and all > others are to demonstrate the cool things of combining containers, > transports - the integration story and they would all get under > samples i.e. > samples/BigBang, samples/SupplyChain .. and so on. > I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: > samples/bingbank > > > das/samples/companyweb > > > sca/samples/calculator > > > sca/services/containers/container.javascript/src/samples/ > calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/samples. These are generally "applications" or as some people like to refer to them "business samples" 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim > - Venkat > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: >> >> I guess I was thinking that the technology type samples would be >> the ones >> that are now moved further down into the folder hierarchy so the only >> thing >> left up at the top would be the business samples so there wasn't >> the need >> for the two folders 'samples' and 'sampleapps' so sampleapps might >> as well >> just be renamed to samples to keep everything consistent. >> >> Please anyone say if they disagree with that. I'd also still like >> to hear >> comments or suggestions on all this from others who've expressed an >> interest >> in the samples in the past before I make the changes - Jim , >> Rick, Simon? >> >> ...ant >> >> On 10/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote: >> > >> > Previously we had discussed having a "sampleapps" directory to >> > distinguish "business samples" from technology samples.[1] Do we >> want >> > to continue this distinction? >> > >> > Brent >> > >> > >> > [1] - >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html >> > >> > On 10/6/06, ant elder <[EMAIL PROTECTED]> wrote: >> > > Ok I think we're getting some agreement but I'd like to be clear >> > everyone >> > > agrees and is happy before I make any changes. Sounds like for >> things >> > like >> > > the Groovy/JavaScript/etc helloworld and calculator type >> samples they >> > would >> > > go with the extension, I'm guessing samples that use just sca >> and java >> > would >> > > go in an sca/samples directory. Samples that use multiple >> extensions >> but >> > > still just SCA would also go in the sca/samples directory, and >> there'd >> > be a >> > > top level samples directory for things like bigbank that use >> > sca/sdo/das. >> > > >> > > So: >> > > >> > > samples/bingbank >> > > das/samples/companyweb >> > > sca/samples/calculator >> > > sca/services/containers/container.javascript/src/samples/ >> calculator >> > > >> > > Comments? >> > > >> > > ...ant >> > > >> > > On 10/5/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> > > > >> > > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote: >> > > > >> > > > > On 10/5/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> > > > >> >> > > > >> 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. >> > > > > >> > > > > >> > > > > I'm not sure I follow "place each sample with the >> implementation >> of >> > > > > the >> > > > > service that it is illustrating" , do you mean something >> like: >> > > > > >> > > > > samples/helloworld/java >> > > > > samples/helloworld/javascript >> > > > > samples/calculator/java >> > > > > samples/calculator/javascript >> > > > > >> > > > > Or do you mean include them with the extension so the >> JavaScript >> > > > > folder >> > > > > would include samples/helloworld and samples/calculator? I >> didn't >> > > > > think Jim >> > > > > liked this way, from the previous thread - "In other >> words, each >> > > > > sample >> > > > > project should not be a sibling to the project containing >> extension >> > > > > code but >> > > > > should go under a samples folder in separate projects". >> > > > I was thinking samples for particular extensions would go >> under the >> > > > particular extension's directory. For samples that used >> multiple >> > > > extensions, they would go under the master samples folder. I >> liked >> > > > what was done with the calculator where stuff is shared between >> > > > projects (component reuse) so if that structuring won't work >> for re- >> > > > use I would be fine with what Ant just outlined. My preference, >> > > > though, would be to group samples with individual extensions. >> > > > >> > > > Jim >> > > > >> > > > > >> > > > > ...ant >> > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > 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] >> > >> > >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]