I believe having those differentiated will make people aware of the relation between sca and tuscany. 'sca-features' and 'sca-extensions' try to make this distinction. Probably 'sca-features' and 'tuscany-features' would be best for us but they are confusing for somebody that is just starting to check tuscany out. In conclusion, we just need to find 2 two self-explaining names. Let's have a day or two for brainstorming that. Feel free to suggest names.
To sum it up, here are some options we have now: sca-features / sca-extensions sca-features / tuscany-features sca-features / sca-additions sca-features / sca-addons sca-features / sca-tuscany-addons sca-spec-features / sca-non-spec-features sca-spec-features / sca-spec-extensions (here extensions can be understood as xep-s are for rfc-s...) On Mon, Sep 20, 2010 at 5:42 PM, Simon Laws <[email protected]>wrote: > On Mon, Sep 20, 2010 at 3:15 PM, Florian MOGA <[email protected]> wrote: > > This morning Ant, Simon L, Kelvin and I had a chat about the samples > > structure. We experimented with it at location [1]. > > The structure is basically the following: > > |-applications > > |---logging-scribe > > |---store > > |---store-webapp > > |-extending-tuscany > > |---implementation-sample > > |-getting-started > > |---helloworld-contribution > > |---helloworld-webapp > > |-running-tuscany > > |---launcher-command-line > > |---launcher-embedded-jse > > |---launcher-embedded-osgi > > |---launcher-embedded-osgi-base > > |---launcher-maven > > |---launcher-osgi > > |---launcher-shell > > |---launcher-webapp > > |-sca-extensions > > |---binding-comet > > |-----weather-webapp > > |---binding-jsonrpc > > |-----calculator-contribution > > |-----calculator-webapp > > |---binding-rmi > > |-----calculator-reference-contribution > > |-----calculator-service-contribution > > |---distributed-osgi > > |-----dosgi-calculator > > |-----dosgi-calculator-operations > > |-----dosgi-dynamic-calculator > > |-----dosgi-dynamic-calculator-operations > > |---implementation-script > > |-----calculator-contribution > > |---implementation-web > > |-----helloworld-jaxrs > > |-----helloworld-js-client > > |-----helloworld-stripes > > |---maven-osgi-junit > > |-----calculator-osgi > > |-----calculator-rest-osgi > > |-sca-features > > |---binding-jms > > |-----helloworld-jms > > |---binding-sca > > |-----calculator-contribution > > |---binding-ws > > |-----calculator-contribution > > |-----helloworld-ws-sdo > > |---implementation-bpel > > |-----helloworld-bpel-contribution > > |-----helloworld-bpel-webapp > > |---implementation-composite > > |-----helloworld-recursive-ws > > |---implementation-java > > |-----calculator-contribution > > |---implementation-spring > > |-----helloworld-spring-contribution > > |-----helloworld-spring-webapp > > |---implementation-web > > |-----helloworld-jsf > > |-----helloworld-jsp > > |-----helloworld-servlet > > |---sca-client > > |-----calculator-scaclient > > |-----helloworld-scaclient > > |---scdl-include > > |-----helloworld-include > > We'd like to move it to trunk, are there any other modifications wanted? > > [1] https://svn.apache.org/repos/asf/tuscany/sandbox/samples/ > > > > I don't think the terms sca-features and sca-extensions work very well. > > sca-features = features that the spec defines > sca-extension = extensions to SCA that Tuscany has made > (the use of the word extension is problematic here as the spec > defines an extension mechanism) > > One approach would be to rename something like: > > sca-features => sca-spec-extensions > sca-extension => tuscany-extensions > > If you feel that this is too confusing let's just go with a "features" > directory after all. This will at least mean that the feature samples > match in some way with the features that the the user will use to > create a classpath to run Tuscany. > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
