+1 for what Jervis, Ant and Simon are saying... I really liked the pre-configured Tomcat installations available for the samples in M1, made my life much easier to get started in Tuscany. I have also recently created that for DAS samples and it's available today at samples/das/testing/tomcat
- Luciano On 8/18/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote: > > 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: [email protected] > > >> > 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] > > > > I agree with Ant. As primarily a user (in the sense that I wanted to understand it and try the samples) of the Java M1 release the presence of the pre-configured Tomcat installation was really handy for quickly running through the samples and getting a feel for what it was all about. As you are constructing a build and distribution system/approach that allows you to cut different distros to suit different requirements for hosting or embedding can you make a standalone samples distro for the interested newbie. No suggestion that this distro would get deployed into production or used other than to get familiar with the technology or bootstrap a development environment? This doesn't suit the hardcore techy who just wants the latest release of the components they are going to refresh into their hand crafted development/test/deployment environment but then they would go and get one of the other distros. Regards Simon
-- ----------------------------------------------------- Luciano Resende SOA Opensource - Apache Tuscany -----------------------------------------------------
