On 2/16/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 2/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> On 16/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >
> > On 2/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I've now removed the Axis2C clients to CppCalculator and CppBigBank.
> > >
> > > Cheers,
> > >
> > >
> > > On 15/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 2/15/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > > starting a new thread for this.
> > > > >
> > > > >
> > > > >
> > > > > On 15/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > OK, it's committed - check out the Sample Dependencies table in
> > > > > >
> > > > > >
> > > >
> >
> 
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/GettingStarted.html
> > > > > > It's a big table (I've split binding extension dependencies into
> > their
> > > > > > service & reference pieces and also specified which container
> each
> > > > > > sample runs under - Axis2C simple HTTP server or HTTPD) - do
> > people
> > > > > > think it helps? Could it be simplified in some way?
> > > > > >
> > > > > > Cheers
> > > > > > Andy
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > >
> > > > > > This is good. It highlights that we can not demo Python or Ruby
> > > > without a
> > > > > ws binding... which is bad IMO.
> > > > >
> > > >
> > > > Agreed. Perhaps we should remove the WS binding elements from all
> the
> > > > *Calculator samples (as we did with CppCalculator), so they only
> have
> > > > local clients.
> > > >
> > > >
> > > > > I think we need a sample for each language extension that requires
> > only
> > > > the
> > > > > core and the particular language extension. I'll experiment with
> > > > creating a
> > > > > ws binding  sample that re-uses the basic cpp calculator sample
> > > > composites.
> > > >
> > > > Sounds good - we only need a single WS-binding oriented sample.
> > > > There's plenty of other examples of the WS (and REST) bindings in
> the
> > > > *BigBank and other samples.
> > > >
> > > > Cheers
> > > > Andy
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> >
> > r508464 adds in an extra table that specifies the external
> > library/runtime dependencies that each sample requires for
> > building/running.
> > See
> >
> 
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/GettingStarted.html
> > again.
> >
> > Cheers
> > Andy
> >
> > -
>
>
> Good work. You may want to have 2 separate columns for Axis2C library and
> server. The CppBigBank sample makes outbound ws calls only so does not
> require the server.

Good point - I left it as a single column as both library & server
come in the the single Axis2C download, but it's worth making it clear
what each sample provides.

> Cheers,
>
>
> --
> Pete
>
Hi Andy

Starting to look useful.

- It looks a little odd (to me:-) that you map samples to Extensions and
then map them again to dependencies. Why didn't you go for
Samples->extensions->dependencies?

I just wanted to make it nice and clear what each sample needed.
Additionally we may have samples that have dependencies that don't
derive from extensions (e.g. the feedparser Python package needed by
the Alert Aggregator sample)

These matrices are for the samples specifically - I agree it will be
good to have a table with the extensions and their dependencies. That
should go in the root GettingStarted.html document.

- There are a few dependencies missing. See (
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Dependencies)

I've added the PHP SCA_SDO package in to the table. SDO C++ (and its
dependencies libxml2, iconv, zlib) is a prerequisites for the SCA
kernel itself, and so these aren't optional like the extensions (and
their dependencies) are.

- In the future i.e. not for M3, I assume we could generate these tables
based on what extensions appear in the sample SCDL

That's a good idea. It wasn't too onerous to build these tables, but
tooling is always useful!

Cheers
Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to