On 3/2/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 01/03/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 3/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > Andrew Borley wrote:
> > > On 3/1/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >> I'm just about at a point where I can produce a release candidate
> which
> > >> includes everything except the PHP extension. I'm wondering if it
> > >> would be
> > >> best to publish this then release the PHP extension as a separate
> > >> entity. We
> > >> could go the whole hog and release a core package and then separate
> > >> packages
> > >> for cpp, Ruby, Python, WS binding etc..
> > >>
> > >> Ultimately I think this is the way to go So If I just want to develop
> in
> > >> Ruby and use REST I can download core, Ruby and Rest extensions and
> not
> > >> worry about the others, and more impoortantly, their dependencies.
> > >>
> > >> Any thoughts?
> > >
> > > +1 from me. I've had some experience of building the PHP extension and
> > > it's quite a process - you need to build PHP with the right flags,
> > > then download and build a particular branch of the PECL SCA_SDO
> > > package and then you can build the Tuscany PHP extension! (see [1])
> > > It may be worth waiting until the AVOCET branch of the SCA_SDO package
> > > becomes the main downloadable package from the PECL site - I believe
> > > this is the plan for the next SCA_SDO release. This (I think) will
> > > remove (or at least vastly simplify) the first 2 steps in the above
> > > process.
> > >
> > > Cheers
> > > Andy
> > >
> > > [1]
> > >
>
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/php/README
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > +1 from me.
> >
> > If I understand correctly then the Tuscany PHP extension will work with
> > an actual release of the PECL SCA_SDO package. Correct?
> >
>
> Not with the current release of the PECL SCA_SDO package (1.1.2), but
> it will with the next release, which will be based on the AVOCET
> branch that the Tuscany PHP extension depends on.
>
> Cheers
> Andy
I can now build the PHP extension and a distro of it's source/binaries
separate from the rest of the release (at leat on Linux for now). I have
some other questions on how we should package the release.
1) Should we produce a source and binary download for core and each
extension? This would produce many download files but would improve the
modularity and flexibility of future releases. e.g. if the Ruby extension
gets a major update there is no need to package, release and test the other
extensions.
I think this is the second time around this loop! I'm happy to go with
the "separate artifacts" plan for the reasons you mention in 1) above,
albeit with the reduced simplicity that you get with a single download
package. Perhaps in the future an installer system could be used that
allows users to get the kernel & the extensions they require.
2) If we do 1) where should the samples go? I think the samples should
belong to the extension that they are demonstrating. This means the language
samples xxxCalculator would be packaged with their extension. THe REST
samples would be in the REST extension (though they would pre-req a language
binding e.g. Python). etc.. An alternative would be to package the samples
separately.
My feeling is that the samples should come with the appropriate
extension. I'd propose:
tuscany_sca_cpp - CppCalculator
tuscany_sca_ruby - RubyCalculator
tuscany_sca_python - PythonCalculator
tuscany_sca_ws - CppBigBank, RubyBigBank, PythonWeatherForecast
tuscany_sca_binding - HTTPDBigBank
tuscany_sca_rest - RestCalculator, RestCustomer, RestYahoo, AlertAggregator
Does that make sense? The WS, REST and SCA binding samples all require
a language extension, but users will need at least one language
extension anyway if they want to do any work with Tuscany!
3) Does anyone ever download the Linux binary release? In my experience the
download source/build/install model is used for the vast majority of Linux
projects. We only produce a binary for a single Linux anyway so unless you
are using RHEL3 you need to go via the source. It may make sense to have a
Mac binary download but again this would be for Mac OS X Intel so of no use
o the PPC Macs.
This is a very valid point! I think we can drop the non-windows binaries.
I would like to implement 1) and have a 3 downloads per extension: Linux/Mac
source, Windows source, Windows binary.
Samples would be included with the relevant extensions.
The extensions would be:
tuscany_sca - the core
tuscany_sca_cpp - C++ language binding
tuscany_sca_ruby - Ruby language binding
tuscany_sca_python - Python language binding
tuscany_sca_ws - Axis2c webservices binding
tuscany_sca_binding - sca binding (based on ws binding)
tuscany_sca_rest - rest binding
3 download artifacts for each.
+1 I think it makes it nice and obvious what technologies are supported.
Cheers
Andy
In regards to 3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
