There are quite a few old threads where we've discussed samples, here's just one of them: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL PROTECTED]
If we're moving towards multiple Tuscany distributions targeted at different areas then i think its fine (and even desirable) for one of those distributions to contain an entire host environment. One of the good things about the M1 release was that it really did make it easy for new users to get started, just "unzip and click on startup". ...ant On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Aug 17, 2006, at 11:21 PM, ant elder wrote: > I agree with Jervis, things just running out-of-box is much nicer > for first > time users than having to fiddle about editing config files. > > Would an alternative be to change the structure of the samples and > move > these technology specific samples into the extension that they use. > For > example, something like having a javascript folder that contained > separate > projects for the JavaScript container and each JavaScript sample. > There > would still be lots of helloworld samples, but not all in the one > top level > samples folder so wouldn't be quite so in your face. I like the idea of moving the samples into the extensions (except maybe the samples that use multiple extensions) and actually think it could correspond to Jeremy's proposal. This would allow us to compartmentalize things more which I think is going to be fundamental to scaling the project. I have several caveats for this though: - there is a clear distinction in the tree between the samples and runtime extension code. 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 - the extensions are individually built from the core projects and fairly autonomous per my previous email - samples are not built with the check-in build for extensions and are separately distributable In terms of end-user experience, I think things are going to vary greatly depending on the host environment. For example, in our standalone environment, things can be automated fairly easily: 1. User downloads core distribution 2. User downloads and drops in sample distribution and starts the standalone core 3. Core reads the dependencies from the sample SCDL and pulls down the required extensions via the ArtifactFactory from a Maven repository. This would resolve the transitive closure of all extension dependencies. This would allow us to track dependencies for extension libraries such as Spring for "free" since most projects publish POMs to a Maven repo. 4. If user chooses, they could avoid step 4 and just download the extension and plug it in Something similar to the above could be done for OSGi except the end user would just deploy a core bundle into an existing OSGi host such as Equinox they had installed. If we are deploying to a servlet container, things will likely be more complex but not too much: 1. User downloads sample application and builds it using Maven, which retrieves the core as a dependency and bundles everything into a war. 2 User deploys the sample war If we "prepackaged" every sample distribution so it could just be dropped in, I think we will wind up with a ton of packaging problems as core will need to be included in every one. I'm pretty firmly against distributions containing an entire host environment, such as Tomcat. I'd prefer we follow projects like Spring, Struts, WebWork, Hibernate (take your pick) and provide distributions which are simple to deploy into containers using some minimal configuration steps. My reason for this is partly practical. First, we should support deploying on a variety of host environments and having to rev versions would be a nightmare. Second, in most data centers I have come across, there is a standard image technologies must accommodate and they will not accept an "bundle of stuff". Jim > > ...ant > > On 8/17/06, Liu, Jervis <[EMAIL PROTECTED]> wrote: >> >> One thing concerns me would be the out-of-box user experience. For >> a first >> time Tuscany user, don't you think it is more user friendly if >> users only >> need to follow the readme, go to a directory, run a common, then >> everything >> works out-of-box? Speaking in my experience, it does encourage me >> to explore >> a new product further if I can set up and run a typical helloworld >> sample >> successfully in 5 minutes without any coding. Well, maybe just me >> being too >> lazy... ;-) >> >> Cheers, >> Jervis >> >> > -----Original Message----- >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, August 17, 2006 6:54 AM >> > To: tuscany-dev@ws.apache.org >> > Subject: Sample framework >> > >> > >> > We have had a rapid increase in the number of samples recently many >> > of which do essentially the same thing. Some feedback from M1 also >> > said that we seemed to have invented the greatest number of >> > varieties >> > of HelloWorld but that it was hard to tell if SCA could do anything >> > else. I'd like to propose a change in how we structure the >> > samples so >> > that we make it clearer to illustrate the technology to users. >> > >> > Rather than having separate projects for each technology >> > variant, I'd >> > like to suggest we have just a couple of projects that provide a >> > framework and then have instructions in the documentation for each >> > technology that clearly show how to apply it. >> > >> > For example, I can see two framework environments: >> > a) a client environment with a simple command line client wires >> > together a couple of local components >> > b) a webapp environment with a simple JSP client that also wires >> > together a couple of local components >> > >> > Then, for example, the JavaScript extension could say: >> > To illustrate the use of JavaScript as a component, take the >> > client a) and >> > 1) replace <implementation.java class="Foo"/> with >> > <implementation.javascript script=" foo.js"/> >> > 2) Install javascript extension >> > 2) rebuild/run sample >> > >> > Or, to illustrate the WebService binding: >> > Server >> > 1) Take webapp and add <service>< binding.ws ...> >> > 2) Install Axis binding extension >> > 3) Deploy server app to Tomcat >> > Client >> > 1) Take client application and replace <component >> name="foo" ...> >> > with <reference><binding.ws ...> >> > 2) Install Axis binding extension >> > 3) Run client >> > >> > The basic idea being, have a common framework and the >> > instructions on >> > how to use the particular extension. >> > -- >> > Jeremy >> > >> > >> --------------------------------------------------------------------- >> > 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]
