If I understand correctly, that makes the webapps folder a subcategory of getting-started. Just to sum it up, the new structure will be something like:
+ getting-started/ - helloworld-* + webapps - helloworld-* + running-tuscany - launcher-* + sca-features - implementation-* - binding-* + applications - store-* - calculator-* Where do the dosgi-* samples fit in (sca-features of applications)? What about the logging-scribe sample? This looks like a really intuitive structure, also not too much fragmentation but enough to make a clean separation. Are we considering promoting some itests to samples? There are some really good callback-api samples (that's what i've checked out some time ago) in the itest folder. On Sun, Sep 12, 2010 at 12:52 PM, Simon Laws <[email protected]>wrote: > > > > I agree about it being a bit disorganized and that makes it hard to > > know where to start, there's so much stuff in the samples folder and > > its all doing different types of things. I think i'd like to move all > > the helloworld type things into a sub folder so as to separate it out > > from the more complex stuff and where appropriate try to build on each > > other eg so the binding.ws contribution reuses one of the helloworld > > contributions etc. Something like this sort of layout: > > > > samples\GettingStarted > > README.txt gives a step by step guide to using the things below > > contributions/ > > - helloworld > > - helloworld-spring > > - helloworld-bpel > > - composites > > - binding.ws > > - binding.jms > > - binding.http > > - etc > > runningTuscany/ > > - Basic Java SE > > - WebApp embedded > > - WebApp With Contributions > > - OSGi > > - Shell > > - SCAClient API > > - Domain > > > > ...ant > > > > Sub-directories sounds like a good direction. I wonder whether we > should separate the "GettingStarted" type samples such as helloworlds > etc. from the "SCAFeatures" type samples which demonstrate individual > extensions, or other features of the SCA sepcifications, at work. > > If we can find opportunities when samples share basic artifacts and > build on one another that, again, sounds like a good idea. It reduces > the amount the new user has to lear in order to understand what SCA is > about. > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
