On Aug 18, 2006, at 6:10 PM, Robbie Minshall wrote:
> Regarding whether or not to embed tomcat with the muscle car
> application
> . . . it is definately just going to come down to a preference
> issue for
> ease of deployment vrs an idealistic build env ( are we teaching
> people to
> deploy, or are we providing an easy avenue for one to showcase SOA
> using SCA
> & SDO - that is the nuts and bolts of the difference here ).
I have the feeling I my previous post didn't explain well...I don't
think we are trying to teach someone how to deploy a war or some type
of archive. I think the goal of the samples should be to teach a
fairly skilled developer how to write applications for the SCA Java
runtime.
In order to teach a developer how to use Java Tuscany, they need to
have the sample source and an easy to use build environment. Just
deploying a binary to a server and watching it run isn't really
helpful. If we take some of the more popular frameworks as guides,
the samples they come with are distributed as source with a build
environment and a minimal bootstrap (in the case of Hibernate), if
anything at all. To take a few:
http://caveatemptor.hibernate.org/2.html
http://www.springframework.org
http://ibatis.apache.org
We can structure the sample build to resolve dependencies through
maven and not have to manage those as part of a distribution.
Moreover, the build can include multiple goals for different target
hosts. Deploying to something like Tomcat or a Servlet engine would
be a simple process of doing something like:
1. Download the sample tar, unzip it
2. Run mvn war
3. cp <war file> <tomcat deploy dir> (or just run the standalone
Tuscany version)
To set up a build environment with all dependencies:
4. mvn idea:idea (or mvn eclipse:eclipse)
5. Add the project created in step 4
To create a full debug environment:
6. Download the tuscany core and extension source tars
7. Attach source to the project dependencies in the IDE
> My view is
> that the working tutorials should be educational and the killer app
> should
> be distributed in a manner that is easy for exec/manager types as
> well as
> developers to get going right off the bat
Hmm, I would say our primary audiences (in order of importance are):
systems developers who want to contribute to Tuscany; and
applications developers who want to use it. I think it is a bit of a
stretch to say execs/managers would bother to download Tuscany.
I agree though it is important to get developers up an running as
quickly as possible with something useful. Given this, do you think
the steps I outlined above are too difficult for a developer to do,
particularly the "average" developer who uses open source (who is
really above average and used to tinkering with things)?
> - though I definately see the
> other side of this argument.
>
>
> Regarding the 'sending the message that people should use SDO/DAS
> instead of O/R technologies such as Hibernate, EJB3, or JDO. How
> about showing how they are complimentary'
> . . . the issue here is that the role and benefits of SDO/RDB
DAS is
> somewhat grey at the present moment. It is clear that providing a
> good
> document show casing the expansion of existing applications using
> Hibernate
> and a POJO model into a service orientated SCA land using the SDO
> functionality across services is key - this is the complimentary
> part and I
> could not possibly agree more ( why Kapel and I are playing with a
> Hibernate
> DAS ).
This would be really cool, for example allowing Hibernate graphs to
be sent to a client. The OpenJPA people also expressed interest in
this and I'd be happy to introduce you to some of them if you are
interested.
> . . . it is also very important for us to have a competitive
> picture and
> story regarding using the RDB DAS for persistence rather than
> solutions such
> as Hibernate/EJB3 etc - this is not so simple and would involve
best
> practices regarding the various performance aspects and the
> disconnected
> graph vrs connected model.
>
This is my own opinion (I mostly like Hibernate even though it has a
few quirks) but I really don't think we want to position SDO/DAS as
competitive to JPA or Hibernate. We would gain more traction if we
worked with popular O/R tools such as Hibernate as instead of
attempting to replace them.
> The samples should address two perspectives: How do I best
migrate my
> application using existing technologies into a SOA application ; If
> I am
> starting from scratch what is the most common, and therefore the
most
> supported technique for model, persistence and exposure.
>
I'm not sure about SDO but one of the key themes of the SCA
collaboration is that SCA can use *existing* technologies and it does
not force people to re-write their applications. Of course it's not
magic and people need to architect things in a service-oriented way
to do this, but the key point is the amount of re-writing is kept to
a minimum. My own preference is to be really cautious about this
since if people perceive SCA as yet another technology that is going
to force them to redo everything we are going to have difficulty
gaining traction.
Jim
> Robbie
>
>
>
>
> On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Aug 18, 2006, at 12:24 PM, Robbie Minshall wrote:
>>
>> > I think that there are two ( ok more than that but still . . . )
>> > types of
>> > samples. One type attempts to demonstrate the muscles of the
>> > technology and
>> > inspire a 'boy this is great, this is better than what I am
>> > currently doing'
>> > thought process. The other is more educational and attempts to
>> > walk the
>> > developer through the development/deployment process while
giving
>> > them a
>> > sense of what they are accomplishing. Both are usefull.
However,
>> > I often
>> > feel that samples get the goals confused and wind up
complicating
>> > the code
>> > of educational sample without providing the appropiate tutorial
>> > updates.
>> >
>> I agree. Petstore is probably an example of this happening.
>>
>> > The key for educational samples is that they should be readable,
>> > should
>> > involve deployment and most importantly a concise accurate
>> > tutorial. They
>> > should not attempt to be the killer app but in the SCA land
should
>> > definately involve plugging in different service implementations
>> > etc as a
>> > part of the tutorial. It is also a little harder than one would
>> > think to
>> > provide documentation etc that clearly indicate to the user
which
>> > application they should use for what goal.
>> >
>> I'm not sure the education samples all need to plug in different
>> impls. Maybe as an "extra". For example, I may only be ever
>> interested in writing Java. Agreed on documentation.
>> > I would recommend two approaches. Providing a simple sample
>> > application
>> > combined with a tutorial for dev, deployment, execution, service
>> > replacement
>> > etc that does not provide an runtime environement such tomcat.
>> Also
>> > providing a fatter muscle flexing sca application combined
with a
>> > up and
>> > runing environement.
>> Agreed on the division but I don't think we need to distribute
a host
>> environment such as Tomcat. For the muscle flexing one (I know
have
>> an image of some 70s muscle car, maybe we can call the sample
>> "chevelle" ;-) ), I think the only practical environment would be
>> standalone or OSGi since J2EE is going to constrain us too much.
>> >
>> > On an aside I am currently working on a simple POJO Hibernate
>> > application
>> > conversion to using SDO and then exposing services via SCA.
Kapel
>> > and I
>> > plan to write a simple tutorial going over the migration and
other
>> > aspects
>> > of this task such as comparing a Hibernate RDB DAS to the SDO
DAS,
>> > and hte
>> > performance cost of using static SDO within our applications
POJO
>> > model.
>> >
>> Hmm, that kind of sends the message that people should use SDO/DAS
>> instead of O/R technologies such as Hibernate, EJB3, or JDO. How
>> about showing how they are complimentary as I think they really
>> address different use cases?
>>
>>
>> > . . . thoughts ?
>> >
>> > Robbie
>> >
>> > On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I think there are a couple issues here which would benefit by
>> >> stepping through what we expect users to actually be doing.
From a
>> >> user standpoint, I imagine most people will have the following
>> goals:
>> >>
>> >> 1. Figure out how to write an SCA application
>> >> 2. Figure out how to deploy the application
>> >> 3. Run the application
>> >>
>> >> Starting with 3 in a server environment does not really do
>> anything.
>> >> For example, I start something up and hit a web page, but can't
>> >> really debug or step through without setting a project up in my
>> IDE.
>> >> What I think most users want is a quick way (i.e 5 minutes) to
>> do the
>> >> following:
>> >>
>> >> 1. Download a sample that has an automated way to create a dev
>> >> project
>> >> 2. Build the sample and deploy it to whatever host
environment I
>> >> typically do my development with. For example, for web app
>> >> development, I prefer Jetty since it is light, fast, and easily
>> >> embedded. Others may prefer Resin, Websphere, WebLogic, etc.
As I
>> >> mention below, however, I don't think most Tuscany development
>> will
>> >> be done inside a web app.
>> >> 3. Run the sample and debug it (either remotely or in my
IDE) so I
>> >> can see what is happening
>> >> 4. Make changes to the sample and goto step 2
>> >>
>> >> The most time-consuming parts I have found in using new
>> technologies
>> >> is getting my dev environment setup properly. For example,
with a
>> >> binary distro, here is what I would have to go through:
>> >>
>> >> 1. Download the binary distro, including a pile of dependencies
>> >> probably totaling over 200MB
>> >> 2. Unzip the distro, follow the readme instructions to start
the
>> >> thing
>> >> 3. Use a browser to hit a web page that prints something out
>> >>
>> >> At this point, I still can't really see what is going on much
>> less do
>> >> things like changing bindings, adding policy, swapping
>> implementation
>> >> types, etc. If I want to use really understand how SCA and
Tuscany
>> >> work, I would have to:
>> >>
>> >> 4. Download the source sample, maybe it is included in 1 but
maybe
>> >> not
>> >> 5. Setup my dev environment with a sample project
>> >> 6. Build the sample and package it
>> >> 7. Figure out whether I want to deal with Tomcat the version of
>> >> Tomcat my Tuscany download just came with. Probably not,
since I
>> >> already have a Tomcat install or use something else.
>> >> 8. Make any necessary changes to my dev environment so I can
debug
>> >> the sample as it is run
>> >> 9. Deploy the sample to the host I do my development with
>> >>
>> >> IMO what would be much simpler for end users would be to:
>> >>
>> >> 1. Download a sample distro
>> >> 2. Build it with maven, which can generate the IDE project for
>> me as
>> >> well as deployment artifacts for whatever host type I choose,
>> e.g. a
>> >> WAR file
>> >> 3. Set my IDE to use the source from the sample I just
downloaded
>> >> 4. Decide where I want to deploy it to. If it is a WAR, I just
>> drop
>> >> it in and either run it from within my IDE and debug or attach
>> to a
>> >> remote process
>> >>
>> >> I think it would be useful to look at projects that have been
>> highly
>> >> successful (i.e. one of the most widely used Java projects) and
>> see
>> >> how they do things, Spring and Hibernate. Both do not ship a
pre-
>> >> configured host environment.
>> >>
>> >> As a further thing to think about, I expect most SCA users will
>> *not*
>> >> be developing with or deploying to Tomcat and will probably
>> instead
>> >> use the standalone version. This is for a number of reasons:
>> >>
>> >> 1. The J2EE deployment model restricts some of the most
important
>> >> features implicit in SCA
>> >> 2. Related to #1, most of the capabilities people really to
>> want to
>> >> see involve things like transactions and policy, dynamic re-
>> wiring,
>> >> etc. which are not directly supported in Tomcat. This will mean
>> >> either having to configure Tomcat with a transaction manager or
>> >> bundling one in the web application. Standalone can handle this
>> >> dynamically. Consequently, I suspect the user experience will
>> be more
>> >> difficult on Tomcat. I also don't think most are going to be
>> >> interested in "helloworld" variants as that can be done more
>> easily
>> >> with existing technologies.
>> >> 3. With dependency injection, there is no need to develop
>> within a
>> >> container - just use mocks. When I build apps, I typically
>> don't get
>> >> them running in a host environment until integration testing.
>> >>
>> >> Jim
>> >>
>> >>
>> >>
>> >> On Aug 18, 2006, at 7:26 AM, Rick wrote:
>> >>
>> >> > +1 for both .. does that make 2? :-)
>> >> > I like the idea of having the bar a low as possible for
>> someone to
>> >> > just start playing with samples to learn building SCA
>> applications.
>> >> > But I also see Jim's point. There are other set of users (IT
>> >> > types) that may not even care about Tomcat and we definitely
>> need
>> >> > to please them too.
>> >> > I think the trick here is to for the site documentation about
>> what
>> >> > download to to satisfy your particular interests is very
>> important
>> >> > and we make perfectly clear that Tuscany is not just a
Tomcat/
>> >> > webserver extension.
>> >> > Luciano Resende wrote:
>> >> >> +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]
>> %3e
>> >> >>> >
>> >> >>> > 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: tuscany-dev-
>> >> >>> [EMAIL PROTECTED]
>> >> >>> > > >> > For additional commands, e-mail: tuscany-dev-
>> >> >>> [EMAIL PROTECTED]
>> >> >>> > > >> >
>> >> >>> > > >> >
>> >> >>> > > >>
>> >> >>> > > >>
>> >> >>>
>> >>
>>
--------------------------------------------------------------------
>> >> >>> -
>> >> >>> > > >> To unsubscribe, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> >>> > > >> For additional commands, e-mail: tuscany-dev-
>> >> >>> [EMAIL PROTECTED]
>> >> >>> > > >>
>> >> >>> > > >>
>> >> >>> > >
>> >> >>> > >
>> >> >>> > >
>> >> >>>
>> >>
>>
--------------------------------------------------------------------
>> >> >>> -
>> >> >>> > > To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >> >>> > > For additional commands, e-mail: tuscany-dev-
>> >> [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
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>>
---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> >
>> >>
>> >>
>> >>
>>
---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > * * * Charlie * * *
>> > Check out some pics of little Charlie at
>> > http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/
>> >
>> > * * * Addresss * * *
>> > 1914 Overland Drive
>> > Chapel Hill
>> > NC 27517
>> >
>> > * * * Number * * *
>> > 919-225-1553
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> * * * Charlie * * *
> Check out some pics of little Charlie at
> http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/
>
> * * * Addresss * * *
> 1914 Overland Drive
> Chapel Hill
> NC 27517
>
> * * * Number * * *
> 919-225-1553
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
