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. 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. 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. 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. Cheers, -- Pete
