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
