On 28/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote: > I'm in the process of porting Tuscany C++ to Mac OSX continuing the work > that Oisin started. Axis2C does not have an OSX port yet (Oisin's > supplied > patch has not been applied) and I've been having a few problems building > their code which are probably simple to solve but I want to focus on > getting > the Tuscany core ported. > > I would like to remove the dependency on Axis2C and make it optional. > > For SDO this would be achieved simply by not building the sdo_axiom > utility > library. > > For SCA it is more complex. FIrst of all we would not build the > current WS > binding extensions. Some of the samples would have to be changed so we do > not build the wsclients which are Axis2C specific. I think we may also > have > to provide a dummy ws binding in place of the Axis2C versions. > > For Linux/Mac we can have a --with-axis2c option on the configure script. > For Windows I changed the build.bat script to optionally build > extensions, > e.g. if PYTHON_HOME is not set then the python extension is not built, > so we > could optionally build with Axis if AXIS2C_HOME is set. It may be > better to > code optional parameters onto the build.bat script to control the > build to > be in line with the Linux build but for now using the environment > variables > is OK. > > Any thoughts? > > Cheers, > Pete, This sounds good to me. A few more thoughts: - +1 for just detecting the AXIS2C_HOME environment variable on Windows, this is more convenient if you build from the IDE as well. - On Linux we already have --enable-wsbinding=yes/no config option. I think we could just change the default to "no", instead of introducing a dummy ws binding and another --with-axis2c config option. - Most of our samples depend on WS on both the client and server side, so turning them into variable geometry samples with an optional WS part sounds a bit complicated :) Could we just use a --enable-wsbinding=yes/no option to enable/disable the samples that require the WS binding? I realize that this will disable most of our current samples but this situation is evolving... We already have a RestCalculator sample that works without the WS binding, I'm about to add another REST sample, Andy is adding a new Python sample, and I'll probably add next a sample that reuses an existing C++ library, which won't use WS either. Soon we'll have enough non-WS samples to illustrate the SCA programming model... and disabling the WS samples won't be a problem. What do you think? -- Jean-Sebastien
binding.ws is part of the core assembly model so we should have at least something that registers to handle those scdl elements. This is my thinking for a dummy/default ws binding extension. When I took out the existing Axis2C ws extension our simple C++ Calculator sample with C++ client fails because the .composite declares a <binding.ws> although this is only used in the ws client case. So I think --enable-wsbinding should always be true and in fact the option would be redundant. Control over who provides the ws binding extension can be with a different switch --with-axis/--with-petes-super-ws-package or whatever. It makes sense to me for the CppCalcualtor sample to conditionally build the wsclient rather than have a separate sample with/without ws. Cheers, -- Pete
