You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2004/08/25 16:47:38 UTC
net access still down in Sri Lanka
The damn cable that the ship broke is still broken .. apparently it
may be down the rest of the week. As a result the Axis/C++ team's
net access is toast, um, sunk.
The Axis/C++ folks here wanted me to report that the planned beta
for the 31st will likely be delayed because of this.
They are however doing some testing with the latest checkout they
had before the lines went dead.
Shit happens. Or should I say ship happens.
Sanjiva.
RE: Generated source in CVS
Posted by Andrew Perry2 <PE...@uk.ibm.com>.
I'm just removing a dependency on j2ee.jar (SocketFactory) then re-testing
and documenting. Hopefully this afternoon, but probably Monday. I'm working
on a structure for building the java services via Ant, and the minimum set
of what is required to be in the deliverable to make it buildable on IBM
WebSphere and AXIS Java. In between builds I'm doing the tcp monitor
automation stuff.
Regards
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828 External + 44 (0)1962 819828
Fax. + 44(0)1962 818080
John
Hawkins/UK/IBM@IB
MGB To
"Apache AXIS C Developers List"
03/09/2004 10:22 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
Re having static tests for e.g. looking at results through tcpmon.
Andrew Perry is implementing a simple automation of handler tests that
spins off a tcpmon like program that puts the result into a file and then
does a compare of the expected result to the actual result.
Andrew - how long until this can go into cvs?
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C Developers List
03/09/2004 07:32 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
On Fri, 2004-09-03 at 11:36, Samisa Abeysinghe wrote:
> --- damitha kumarage <da...@opensource.lk> wrote:
>
> >
> > On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> > > Sounds like we are in sync on this.
> > >
> > > I think we have bulk of the required functionality with the auto
build and test suite scripts
> > we
> > > have got. (BTW: do we have Windows versions of these now?)
> > >
> > > Damitha! Are we going to remove the generated code for the existing
samples/tests from cvs?
> >
> > I think samples sould be static and in the build time samples should be
> > built. But the tests should not be static and code should be generated
> > when running the test suite.
> > For a average user who intend to down load and see the samples running
> > ./configure ...
> > make
> > make install
> > deploy the service samples and run the client samples
> >
> >
> > For a developer who needs to see whether everything is ok before he
> > commits his changes.
> > cd $AXISCPP_HOME/tests/auto_build
> >
> > sh autoBuildCVS.sh
> > This should
> > 1. merge his changes
> > 2. source build
> > 3. generage tests
> > 4. deploy service tests
> > 5. run client tests
> >
> > Therefore my suggestion is that we need to have all the tests in the
> > auto_build/testcases folder. If we need any static tests then we can
put
> > them
> > in $AXISCPP_HOME/tests folder as well. But in this case code should not
> > be generated for testing. All the required files should be in place.
> > In this sense uddi_inquire test should not be placed in
> > $AXISCPP_HOME/tests. It should be in
> > $AXISCPP_HOME/tests/auto_build/testcases
>
> This does not sound correct to me. This sounds like lot of duplication
(same test in 2 places)
>
> Why cant we use the tests in $AXISCPP_HOME/tests from
$AXISCPP_HOME/tests/auto_build/testcases?
> I do not understand the need for seperation of dynamic and static.
> I thought we are using $AXISCPP_HOME/tests from within
$AXISCPP_HOME/tests/auto_build/testcases.
under $AXISCPP_HOME/tests/auto_build/testcases we have seperate folder
to keep wsdls and another folder to keep client .cpp files(not
generated). When it builds it creates the folder <wsdlname>Client.cpp in
$AXISCPP_HOME/tests/auto_build/testcases/build and generate the files
and copy the client .cpp file to that place and build.
Why we need a static tests is for the following reason. Some tests are
there you can check the test only by looking at the response result on
tcpmon. eg. to test whether handler add a response header.
Actually there should be no test duplication. I am suggesting to move
all the tests to auto_build/testcases folder from tests folder unless
you need it there for some specific reason as the example mentioned
above.
>
> I do not think that we need the generated code at all, because if someone
is to use Axis C++
> he/she must have the WSDL2WS tool. Hence I see no point in putting the
generated code in cvs,
> whether the test is static or not.
>
> The greatest trouble I have is that the cvs chekout takes hours when the
network is slow, and most
> of the time is spent on downloading the code that I could have easily
generated locally.
>
> For those users who need to have a look at the samples, the generated
code is not required to be
> packaged. They can generate and see if they want.
The problem here is that if the samples files are to be generated at
build time how to do that in make make install process?
Does the ant build for c++ make the life easier in this respect?
thanks
damitha
>
> Samisa...
>
>
> >
> > thanks
> > damitha
> > >
> > > Samisa...
> > >
> > > --- damitha kumarage <da...@opensource.lk> wrote:
> > >
> > > > Forgive me been so late on commenting on this. But, is not it
better if
> > > > we coordinate these two, I mean build verification and regression
test
> > > > into a single test process. This shoud
> > > > 1 CVS checkout
> > > > 2 Source build
> > > > 3 code generation for both client adn service
> > > > 4 deploy services
> > > > 5 run clients
> > > >
> > > > thanks
> > > > damitha
> > > > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > > > >
> > > > >
> > > > > Agreed - we should not mix up build and testing.
> > > > > If we use the building of the clients using the WSDL2WS from that
build
> > > > > then this is a very useful build verification test e.g.
> > > > >
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we
need the
> > > > > WSDL, preferrably stored
> > > > > localy) this is a Build verification test (BVT)
> > > > >
> > > > > If build verification works then test against services.......
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > > This is the Regression test
> > > > >
> > > > > John Hawkins
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Samisa Abeysinghe
> > > > > <samisa_abeysingh
> > > > > e@yahoo.com>
To
> > > > > Apache AXIS C Developers
List
> > > > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > > >
cc
> > > > >
> > > > > Please respond to
Subject
> > > > > "Apache AXIS C RE: Generated source in
CVS
> > > > > Developers List"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > When we run a test it would be nice if the wsdl is downloaded
into the
> > > > > > wsdl folder and generate stubs and then run the test. I guest
being able
> > > > > > to download the wsdl implies that the web service is running?.
> > > > > >
> > > > >
> > > > > If we are talking about the automated CVS build test, is it
practical to
> > > > > assume that the service
> > > > > is running?
> > > > >
> > > > > If you think of the steps.
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we
need the
> > > > > WSDL, preferrably stored
> > > > > localy)
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > >
> > > > > Steps 2-5 would require logging.
> > > > >
> > > > > Samisa...
> > > > >
> > > > >
> > > > >
> > > > > _______________________________
> > > > > Do you Yahoo!?
> > > > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > > > http://promotions.yahoo.com/goldrush
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail is new and improved - Check it out!
> > > http://promotions.yahoo.com/new_mail
> > >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
Re having static tests for e.g. looking at results through tcpmon.
Andrew Perry is implementing a simple automation of handler tests that
spins off a tcpmon like program that puts the result into a file and then
does a compare of the expected result to the actual result.
Andrew - how long until this can go into cvs?
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C Developers List
03/09/2004 07:32 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
On Fri, 2004-09-03 at 11:36, Samisa Abeysinghe wrote:
> --- damitha kumarage <da...@opensource.lk> wrote:
>
> >
> > On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> > > Sounds like we are in sync on this.
> > >
> > > I think we have bulk of the required functionality with the auto
build and test suite scripts
> > we
> > > have got. (BTW: do we have Windows versions of these now?)
> > >
> > > Damitha! Are we going to remove the generated code for the existing
samples/tests from cvs?
> >
> > I think samples sould be static and in the build time samples should be
> > built. But the tests should not be static and code should be generated
> > when running the test suite.
> > For a average user who intend to down load and see the samples running
> > ./configure ...
> > make
> > make install
> > deploy the service samples and run the client samples
> >
> >
> > For a developer who needs to see whether everything is ok before he
> > commits his changes.
> > cd $AXISCPP_HOME/tests/auto_build
> >
> > sh autoBuildCVS.sh
> > This should
> > 1. merge his changes
> > 2. source build
> > 3. generage tests
> > 4. deploy service tests
> > 5. run client tests
> >
> > Therefore my suggestion is that we need to have all the tests in the
> > auto_build/testcases folder. If we need any static tests then we can
put
> > them
> > in $AXISCPP_HOME/tests folder as well. But in this case code should not
> > be generated for testing. All the required files should be in place.
> > In this sense uddi_inquire test should not be placed in
> > $AXISCPP_HOME/tests. It should be in
> > $AXISCPP_HOME/tests/auto_build/testcases
>
> This does not sound correct to me. This sounds like lot of duplication
(same test in 2 places)
>
> Why cant we use the tests in $AXISCPP_HOME/tests from
$AXISCPP_HOME/tests/auto_build/testcases?
> I do not understand the need for seperation of dynamic and static.
> I thought we are using $AXISCPP_HOME/tests from within
$AXISCPP_HOME/tests/auto_build/testcases.
under $AXISCPP_HOME/tests/auto_build/testcases we have seperate folder
to keep wsdls and another folder to keep client .cpp files(not
generated). When it builds it creates the folder <wsdlname>Client.cpp in
$AXISCPP_HOME/tests/auto_build/testcases/build and generate the files
and copy the client .cpp file to that place and build.
Why we need a static tests is for the following reason. Some tests are
there you can check the test only by looking at the response result on
tcpmon. eg. to test whether handler add a response header.
Actually there should be no test duplication. I am suggesting to move
all the tests to auto_build/testcases folder from tests folder unless
you need it there for some specific reason as the example mentioned
above.
>
> I do not think that we need the generated code at all, because if someone
is to use Axis C++
> he/she must have the WSDL2WS tool. Hence I see no point in putting the
generated code in cvs,
> whether the test is static or not.
>
> The greatest trouble I have is that the cvs chekout takes hours when the
network is slow, and most
> of the time is spent on downloading the code that I could have easily
generated locally.
>
> For those users who need to have a look at the samples, the generated
code is not required to be
> packaged. They can generate and see if they want.
The problem here is that if the samples files are to be generated at
build time how to do that in make make install process?
Does the ant build for c++ make the life easier in this respect?
thanks
damitha
>
> Samisa...
>
>
> >
> > thanks
> > damitha
> > >
> > > Samisa...
> > >
> > > --- damitha kumarage <da...@opensource.lk> wrote:
> > >
> > > > Forgive me been so late on commenting on this. But, is not it
better if
> > > > we coordinate these two, I mean build verification and regression
test
> > > > into a single test process. This shoud
> > > > 1 CVS checkout
> > > > 2 Source build
> > > > 3 code generation for both client adn service
> > > > 4 deploy services
> > > > 5 run clients
> > > >
> > > > thanks
> > > > damitha
> > > > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > > > >
> > > > >
> > > > > Agreed - we should not mix up build and testing.
> > > > > If we use the building of the clients using the WSDL2WS from that
build
> > > > > then this is a very useful build verification test e.g.
> > > > >
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we
need the
> > > > > WSDL, preferrably stored
> > > > > localy) this is a Build verification test (BVT)
> > > > >
> > > > > If build verification works then test against services.......
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > > This is the Regression test
> > > > >
> > > > > John Hawkins
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Samisa Abeysinghe
> > > > > <samisa_abeysingh
> > > > > e@yahoo.com>
To
> > > > > Apache AXIS C Developers
List
> > > > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > > >
cc
> > > > >
> > > > > Please respond to
Subject
> > > > > "Apache AXIS C RE: Generated source in
CVS
> > > > > Developers List"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > When we run a test it would be nice if the wsdl is downloaded
into the
> > > > > > wsdl folder and generate stubs and then run the test. I guest
being able
> > > > > > to download the wsdl implies that the web service is running?.
> > > > > >
> > > > >
> > > > > If we are talking about the automated CVS build test, is it
practical to
> > > > > assume that the service
> > > > > is running?
> > > > >
> > > > > If you think of the steps.
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we
need the
> > > > > WSDL, preferrably stored
> > > > > localy)
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > >
> > > > > Steps 2-5 would require logging.
> > > > >
> > > > > Samisa...
> > > > >
> > > > >
> > > > >
> > > > > _______________________________
> > > > > Do you Yahoo!?
> > > > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > > > http://promotions.yahoo.com/goldrush
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail is new and improved - Check it out!
> > > http://promotions.yahoo.com/new_mail
> > >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
> The problem here is that if the samples files are to be generated at
> build time how to do that in make make install process?
> Does the ant build for c++ make the life easier in this respect?
Yes ant will make this possible.
However I guess that we could get the same done with make. Need to do a bit of research on this.
Samisa...
--- damitha kumarage <da...@opensource.lk> wrote:
> On Fri, 2004-09-03 at 11:36, Samisa Abeysinghe wrote:
> > --- damitha kumarage <da...@opensource.lk> wrote:
> >
> > >
> > > On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> > > > Sounds like we are in sync on this.
> > > >
> > > > I think we have bulk of the required functionality with the auto build and test suite
> scripts
> > > we
> > > > have got. (BTW: do we have Windows versions of these now?)
> > > >
> > > > Damitha! Are we going to remove the generated code for the existing samples/tests from
> cvs?
> > >
> > > I think samples sould be static and in the build time samples should be
> > > built. But the tests should not be static and code should be generated
> > > when running the test suite.
> > > For a average user who intend to down load and see the samples running
> > > ./configure ...
> > > make
> > > make install
> > > deploy the service samples and run the client samples
> > >
> > >
> > > For a developer who needs to see whether everything is ok before he
> > > commits his changes.
> > > cd $AXISCPP_HOME/tests/auto_build
> > >
> > > sh autoBuildCVS.sh
> > > This should
> > > 1. merge his changes
> > > 2. source build
> > > 3. generage tests
> > > 4. deploy service tests
> > > 5. run client tests
> > >
> > > Therefore my suggestion is that we need to have all the tests in the
> > > auto_build/testcases folder. If we need any static tests then we can put
> > > them
> > > in $AXISCPP_HOME/tests folder as well. But in this case code should not
> > > be generated for testing. All the required files should be in place.
> > > In this sense uddi_inquire test should not be placed in
> > > $AXISCPP_HOME/tests. It should be in
> > > $AXISCPP_HOME/tests/auto_build/testcases
> >
> > This does not sound correct to me. This sounds like lot of duplication (same test in 2 places)
> >
> > Why cant we use the tests in $AXISCPP_HOME/tests from
> $AXISCPP_HOME/tests/auto_build/testcases?
> > I do not understand the need for seperation of dynamic and static.
> > I thought we are using $AXISCPP_HOME/tests from within
> $AXISCPP_HOME/tests/auto_build/testcases.
> under $AXISCPP_HOME/tests/auto_build/testcases we have seperate folder
> to keep wsdls and another folder to keep client .cpp files(not
> generated). When it builds it creates the folder <wsdlname>Client.cpp in
> $AXISCPP_HOME/tests/auto_build/testcases/build and generate the files
> and copy the client .cpp file to that place and build.
>
> Why we need a static tests is for the following reason. Some tests are
> there you can check the test only by looking at the response result on
> tcpmon. eg. to test whether handler add a response header.
>
> Actually there should be no test duplication. I am suggesting to move
> all the tests to auto_build/testcases folder from tests folder unless
> you need it there for some specific reason as the example mentioned
> above.
>
>
>
> >
> > I do not think that we need the generated code at all, because if someone is to use Axis C++
> > he/she must have the WSDL2WS tool. Hence I see no point in putting the generated code in cvs,
> > whether the test is static or not.
> >
> > The greatest trouble I have is that the cvs chekout takes hours when the network is slow, and
> most
> > of the time is spent on downloading the code that I could have easily generated locally.
> >
> > For those users who need to have a look at the samples, the generated code is not required to
> be
> > packaged. They can generate and see if they want.
>
>
> thanks
> damitha
> >
> > Samisa...
> >
> >
> > >
> > > thanks
> > > damitha
> > > >
> > > > Samisa...
> > > >
> > > > --- damitha kumarage <da...@opensource.lk> wrote:
> > > >
> > > > > Forgive me been so late on commenting on this. But, is not it better if
> > > > > we coordinate these two, I mean build verification and regression test
> > > > > into a single test process. This shoud
> > > > > 1 CVS checkout
> > > > > 2 Source build
> > > > > 3 code generation for both client adn service
> > > > > 4 deploy services
> > > > > 5 run clients
> > > > >
> > > > > thanks
> > > > > damitha
> > > > > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > > > > >
> > > > > >
> > > > > > Agreed - we should not mix up build and testing.
> > > > > > If we use the building of the clients using the WSDL2WS from that build
> > > > > > then this is a very useful build verification test e.g.
> > > > > >
> > > > > > 1. CVS checkout
> > > > > > 2. Source build
> > > > > > 3. Code generation for both client and service (at this point we need the
> > > > > > WSDL, preferrably stored
> > > > > > localy) this is a Build verification test (BVT)
> > > > > >
> > > > > > If build verification works then test against services.......
> > > > > > 4. Deploy services
> > > > > > 5. Run clients
> > > > > > This is the Regression test
> > > > > >
> > > > > > John Hawkins
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Samisa Abeysinghe
> > > > > > <samisa_abeysingh
> > > > > > e@yahoo.com> To
> > > > > > Apache AXIS C Developers List
> > > > > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > > > > cc
> > > > > >
> > > > > > Please respond to Subject
> > > > > > "Apache AXIS C RE: Generated source in CVS
> > > > > > Developers List"
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > When we run a test it would be nice if the wsdl is downloaded into the
> > > > > > > wsdl folder and generate stubs and then run the test. I guest being able
> > > > > > > to download the wsdl implies that the web service is running?.
> > > > > > >
> > > > > >
> > > > > > If we are talking about the automated CVS build test, is it practical to
> > > > > > assume that the service
> > > > > > is running?
> > > > > >
> > > > > > If you think of the steps.
> > > > > > 1. CVS checkout
> > > > > > 2. Source build
> > > > > > 3. Code generation for both client and service (at this point we need the
> > > > > > WSDL, preferrably stored
> > > > > > localy)
> > > > > > 4. Deploy services
> > > > > > 5. Run clients
> > > > > >
> > > > > > Steps 2-5 would require logging.
> > > > > >
> > > > > > Samisa...
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________
> > > > > > Do you Yahoo!?
> > > > > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > > > > http://promotions.yahoo.com/goldrush
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Mail is new and improved - Check it out!
> > > > http://promotions.yahoo.com/new_mail
> > > >
> > >
> > >
>
=== message truncated ===
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
RE: Generated source in CVS
Posted by damitha kumarage <da...@opensource.lk>.
On Fri, 2004-09-03 at 11:36, Samisa Abeysinghe wrote:
> --- damitha kumarage <da...@opensource.lk> wrote:
>
> >
> > On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> > > Sounds like we are in sync on this.
> > >
> > > I think we have bulk of the required functionality with the auto build and test suite scripts
> > we
> > > have got. (BTW: do we have Windows versions of these now?)
> > >
> > > Damitha! Are we going to remove the generated code for the existing samples/tests from cvs?
> >
> > I think samples sould be static and in the build time samples should be
> > built. But the tests should not be static and code should be generated
> > when running the test suite.
> > For a average user who intend to down load and see the samples running
> > ./configure ...
> > make
> > make install
> > deploy the service samples and run the client samples
> >
> >
> > For a developer who needs to see whether everything is ok before he
> > commits his changes.
> > cd $AXISCPP_HOME/tests/auto_build
> >
> > sh autoBuildCVS.sh
> > This should
> > 1. merge his changes
> > 2. source build
> > 3. generage tests
> > 4. deploy service tests
> > 5. run client tests
> >
> > Therefore my suggestion is that we need to have all the tests in the
> > auto_build/testcases folder. If we need any static tests then we can put
> > them
> > in $AXISCPP_HOME/tests folder as well. But in this case code should not
> > be generated for testing. All the required files should be in place.
> > In this sense uddi_inquire test should not be placed in
> > $AXISCPP_HOME/tests. It should be in
> > $AXISCPP_HOME/tests/auto_build/testcases
>
> This does not sound correct to me. This sounds like lot of duplication (same test in 2 places)
>
> Why cant we use the tests in $AXISCPP_HOME/tests from $AXISCPP_HOME/tests/auto_build/testcases?
> I do not understand the need for seperation of dynamic and static.
> I thought we are using $AXISCPP_HOME/tests from within $AXISCPP_HOME/tests/auto_build/testcases.
under $AXISCPP_HOME/tests/auto_build/testcases we have seperate folder
to keep wsdls and another folder to keep client .cpp files(not
generated). When it builds it creates the folder <wsdlname>Client.cpp in
$AXISCPP_HOME/tests/auto_build/testcases/build and generate the files
and copy the client .cpp file to that place and build.
Why we need a static tests is for the following reason. Some tests are
there you can check the test only by looking at the response result on
tcpmon. eg. to test whether handler add a response header.
Actually there should be no test duplication. I am suggesting to move
all the tests to auto_build/testcases folder from tests folder unless
you need it there for some specific reason as the example mentioned
above.
>
> I do not think that we need the generated code at all, because if someone is to use Axis C++
> he/she must have the WSDL2WS tool. Hence I see no point in putting the generated code in cvs,
> whether the test is static or not.
>
> The greatest trouble I have is that the cvs chekout takes hours when the network is slow, and most
> of the time is spent on downloading the code that I could have easily generated locally.
>
> For those users who need to have a look at the samples, the generated code is not required to be
> packaged. They can generate and see if they want.
The problem here is that if the samples files are to be generated at
build time how to do that in make make install process?
Does the ant build for c++ make the life easier in this respect?
thanks
damitha
>
> Samisa...
>
>
> >
> > thanks
> > damitha
> > >
> > > Samisa...
> > >
> > > --- damitha kumarage <da...@opensource.lk> wrote:
> > >
> > > > Forgive me been so late on commenting on this. But, is not it better if
> > > > we coordinate these two, I mean build verification and regression test
> > > > into a single test process. This shoud
> > > > 1 CVS checkout
> > > > 2 Source build
> > > > 3 code generation for both client adn service
> > > > 4 deploy services
> > > > 5 run clients
> > > >
> > > > thanks
> > > > damitha
> > > > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > > > >
> > > > >
> > > > > Agreed - we should not mix up build and testing.
> > > > > If we use the building of the clients using the WSDL2WS from that build
> > > > > then this is a very useful build verification test e.g.
> > > > >
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we need the
> > > > > WSDL, preferrably stored
> > > > > localy) this is a Build verification test (BVT)
> > > > >
> > > > > If build verification works then test against services.......
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > > This is the Regression test
> > > > >
> > > > > John Hawkins
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Samisa Abeysinghe
> > > > > <samisa_abeysingh
> > > > > e@yahoo.com> To
> > > > > Apache AXIS C Developers List
> > > > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > > > cc
> > > > >
> > > > > Please respond to Subject
> > > > > "Apache AXIS C RE: Generated source in CVS
> > > > > Developers List"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > When we run a test it would be nice if the wsdl is downloaded into the
> > > > > > wsdl folder and generate stubs and then run the test. I guest being able
> > > > > > to download the wsdl implies that the web service is running?.
> > > > > >
> > > > >
> > > > > If we are talking about the automated CVS build test, is it practical to
> > > > > assume that the service
> > > > > is running?
> > > > >
> > > > > If you think of the steps.
> > > > > 1. CVS checkout
> > > > > 2. Source build
> > > > > 3. Code generation for both client and service (at this point we need the
> > > > > WSDL, preferrably stored
> > > > > localy)
> > > > > 4. Deploy services
> > > > > 5. Run clients
> > > > >
> > > > > Steps 2-5 would require logging.
> > > > >
> > > > > Samisa...
> > > > >
> > > > >
> > > > >
> > > > > _______________________________
> > > > > Do you Yahoo!?
> > > > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > > > http://promotions.yahoo.com/goldrush
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail is new and improved - Check it out!
> > > http://promotions.yahoo.com/new_mail
> > >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- damitha kumarage <da...@opensource.lk> wrote:
>
> On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> > Sounds like we are in sync on this.
> >
> > I think we have bulk of the required functionality with the auto build and test suite scripts
> we
> > have got. (BTW: do we have Windows versions of these now?)
> >
> > Damitha! Are we going to remove the generated code for the existing samples/tests from cvs?
>
> I think samples sould be static and in the build time samples should be
> built. But the tests should not be static and code should be generated
> when running the test suite.
> For a average user who intend to down load and see the samples running
> ./configure ...
> make
> make install
> deploy the service samples and run the client samples
>
>
> For a developer who needs to see whether everything is ok before he
> commits his changes.
> cd $AXISCPP_HOME/tests/auto_build
>
> sh autoBuildCVS.sh
> This should
> 1. merge his changes
> 2. source build
> 3. generage tests
> 4. deploy service tests
> 5. run client tests
>
> Therefore my suggestion is that we need to have all the tests in the
> auto_build/testcases folder. If we need any static tests then we can put
> them
> in $AXISCPP_HOME/tests folder as well. But in this case code should not
> be generated for testing. All the required files should be in place.
> In this sense uddi_inquire test should not be placed in
> $AXISCPP_HOME/tests. It should be in
> $AXISCPP_HOME/tests/auto_build/testcases
This does not sound correct to me. This sounds like lot of duplication (same test in 2 places)
Why cant we use the tests in $AXISCPP_HOME/tests from $AXISCPP_HOME/tests/auto_build/testcases?
I do not understand the need for seperation of dynamic and static.
I thought we are using $AXISCPP_HOME/tests from within $AXISCPP_HOME/tests/auto_build/testcases.
I do not think that we need the generated code at all, because if someone is to use Axis C++
he/she must have the WSDL2WS tool. Hence I see no point in putting the generated code in cvs,
whether the test is static or not.
The greatest trouble I have is that the cvs chekout takes hours when the network is slow, and most
of the time is spent on downloading the code that I could have easily generated locally.
For those users who need to have a look at the samples, the generated code is not required to be
packaged. They can generate and see if they want.
Samisa...
>
> thanks
> damitha
> >
> > Samisa...
> >
> > --- damitha kumarage <da...@opensource.lk> wrote:
> >
> > > Forgive me been so late on commenting on this. But, is not it better if
> > > we coordinate these two, I mean build verification and regression test
> > > into a single test process. This shoud
> > > 1 CVS checkout
> > > 2 Source build
> > > 3 code generation for both client adn service
> > > 4 deploy services
> > > 5 run clients
> > >
> > > thanks
> > > damitha
> > > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > > >
> > > >
> > > > Agreed - we should not mix up build and testing.
> > > > If we use the building of the clients using the WSDL2WS from that build
> > > > then this is a very useful build verification test e.g.
> > > >
> > > > 1. CVS checkout
> > > > 2. Source build
> > > > 3. Code generation for both client and service (at this point we need the
> > > > WSDL, preferrably stored
> > > > localy) this is a Build verification test (BVT)
> > > >
> > > > If build verification works then test against services.......
> > > > 4. Deploy services
> > > > 5. Run clients
> > > > This is the Regression test
> > > >
> > > > John Hawkins
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Samisa Abeysinghe
> > > > <samisa_abeysingh
> > > > e@yahoo.com> To
> > > > Apache AXIS C Developers List
> > > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > > cc
> > > >
> > > > Please respond to Subject
> > > > "Apache AXIS C RE: Generated source in CVS
> > > > Developers List"
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > When we run a test it would be nice if the wsdl is downloaded into the
> > > > > wsdl folder and generate stubs and then run the test. I guest being able
> > > > > to download the wsdl implies that the web service is running?.
> > > > >
> > > >
> > > > If we are talking about the automated CVS build test, is it practical to
> > > > assume that the service
> > > > is running?
> > > >
> > > > If you think of the steps.
> > > > 1. CVS checkout
> > > > 2. Source build
> > > > 3. Code generation for both client and service (at this point we need the
> > > > WSDL, preferrably stored
> > > > localy)
> > > > 4. Deploy services
> > > > 5. Run clients
> > > >
> > > > Steps 2-5 would require logging.
> > > >
> > > > Samisa...
> > > >
> > > >
> > > >
> > > > _______________________________
> > > > Do you Yahoo!?
> > > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > > http://promotions.yahoo.com/goldrush
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail is new and improved - Check it out!
> > http://promotions.yahoo.com/new_mail
> >
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
RE: Generated source in CVS
Posted by damitha kumarage <da...@opensource.lk>.
On Fri, 2004-09-03 at 10:09, Samisa Abeysinghe wrote:
> Sounds like we are in sync on this.
>
> I think we have bulk of the required functionality with the auto build and test suite scripts we
> have got. (BTW: do we have Windows versions of these now?)
>
> Damitha! Are we going to remove the generated code for the existing samples/tests from cvs?
I think samples sould be static and in the build time samples should be
built. But the tests should not be static and code should be generated
when running the test suite.
For a average user who intend to down load and see the samples running
./configure ...
make
make install
deploy the service samples and run the client samples
For a developer who needs to see whether everything is ok before he
commits his changes.
cd $AXISCPP_HOME/tests/auto_build
sh autoBuildCVS.sh
This should
1. merge his changes
2. source build
3. generage tests
4. deploy service tests
5. run client tests
Therefore my suggestion is that we need to have all the tests in the
auto_build/testcases folder. If we need any static tests then we can put
them
in $AXISCPP_HOME/tests folder as well. But in this case code should not
be generated for testing. All the required files should be in place.
In this sense uddi_inquire test should not be placed in
$AXISCPP_HOME/tests. It should be in
$AXISCPP_HOME/tests/auto_build/testcases
thanks
damitha
>
> Samisa...
>
> --- damitha kumarage <da...@opensource.lk> wrote:
>
> > Forgive me been so late on commenting on this. But, is not it better if
> > we coordinate these two, I mean build verification and regression test
> > into a single test process. This shoud
> > 1 CVS checkout
> > 2 Source build
> > 3 code generation for both client adn service
> > 4 deploy services
> > 5 run clients
> >
> > thanks
> > damitha
> > On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> > >
> > >
> > > Agreed - we should not mix up build and testing.
> > > If we use the building of the clients using the WSDL2WS from that build
> > > then this is a very useful build verification test e.g.
> > >
> > > 1. CVS checkout
> > > 2. Source build
> > > 3. Code generation for both client and service (at this point we need the
> > > WSDL, preferrably stored
> > > localy) this is a Build verification test (BVT)
> > >
> > > If build verification works then test against services.......
> > > 4. Deploy services
> > > 5. Run clients
> > > This is the Regression test
> > >
> > > John Hawkins
> > >
> > >
> > >
> > >
> > >
> > > Samisa Abeysinghe
> > > <samisa_abeysingh
> > > e@yahoo.com> To
> > > Apache AXIS C Developers List
> > > 28/08/2004 03:19 <ax...@ws.apache.org>
> > > cc
> > >
> > > Please respond to Subject
> > > "Apache AXIS C RE: Generated source in CVS
> > > Developers List"
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > When we run a test it would be nice if the wsdl is downloaded into the
> > > > wsdl folder and generate stubs and then run the test. I guest being able
> > > > to download the wsdl implies that the web service is running?.
> > > >
> > >
> > > If we are talking about the automated CVS build test, is it practical to
> > > assume that the service
> > > is running?
> > >
> > > If you think of the steps.
> > > 1. CVS checkout
> > > 2. Source build
> > > 3. Code generation for both client and service (at this point we need the
> > > WSDL, preferrably stored
> > > localy)
> > > 4. Deploy services
> > > 5. Run clients
> > >
> > > Steps 2-5 would require logging.
> > >
> > > Samisa...
> > >
> > >
> > >
> > > _______________________________
> > > Do you Yahoo!?
> > > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > > http://promotions.yahoo.com/goldrush
> > >
> > >
> > >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Sounds like we are in sync on this.
I think we have bulk of the required functionality with the auto build and test suite scripts we
have got. (BTW: do we have Windows versions of these now?)
Damitha! Are we going to remove the generated code for the existing samples/tests from cvs?
Samisa...
--- damitha kumarage <da...@opensource.lk> wrote:
> Forgive me been so late on commenting on this. But, is not it better if
> we coordinate these two, I mean build verification and regression test
> into a single test process. This shoud
> 1 CVS checkout
> 2 Source build
> 3 code generation for both client adn service
> 4 deploy services
> 5 run clients
>
> thanks
> damitha
> On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
> >
> >
> > Agreed - we should not mix up build and testing.
> > If we use the building of the clients using the WSDL2WS from that build
> > then this is a very useful build verification test e.g.
> >
> > 1. CVS checkout
> > 2. Source build
> > 3. Code generation for both client and service (at this point we need the
> > WSDL, preferrably stored
> > localy) this is a Build verification test (BVT)
> >
> > If build verification works then test against services.......
> > 4. Deploy services
> > 5. Run clients
> > This is the Regression test
> >
> > John Hawkins
> >
> >
> >
> >
> >
> > Samisa Abeysinghe
> > <samisa_abeysingh
> > e@yahoo.com> To
> > Apache AXIS C Developers List
> > 28/08/2004 03:19 <ax...@ws.apache.org>
> > cc
> >
> > Please respond to Subject
> > "Apache AXIS C RE: Generated source in CVS
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > When we run a test it would be nice if the wsdl is downloaded into the
> > > wsdl folder and generate stubs and then run the test. I guest being able
> > > to download the wsdl implies that the web service is running?.
> > >
> >
> > If we are talking about the automated CVS build test, is it practical to
> > assume that the service
> > is running?
> >
> > If you think of the steps.
> > 1. CVS checkout
> > 2. Source build
> > 3. Code generation for both client and service (at this point we need the
> > WSDL, preferrably stored
> > localy)
> > 4. Deploy services
> > 5. Run clients
> >
> > Steps 2-5 would require logging.
> >
> > Samisa...
> >
> >
> >
> > _______________________________
> > Do you Yahoo!?
> > Win 1 of 4,000 free domain names from Yahoo! Enter now.
> > http://promotions.yahoo.com/goldrush
> >
> >
> >
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
This is not correct for the way that we will be running here. We have many
machines one is a build machine and one is the teest machine. The build
machine does what it says and builds ONLY (with the verification that the
cuild is OK as whether the tests built (not ran) or not). The output is
then put onto the test machine which then runs the tests. We do not bother
to run the tests if the build verification tests (BVT) fail.
I don't believe it is correct to say that BVT is the same cycle as
regression test - they are distinct processes.
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C Developers List
03/09/2004 04:33 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
Forgive me been so late on commenting on this. But, is not it better if
we coordinate these two, I mean build verification and regression test
into a single test process. This shoud
1 CVS checkout
2 Source build
3 code generation for both client adn service
4 deploy services
5 run clients
thanks
damitha
On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
>
>
> Agreed - we should not mix up build and testing.
> If we use the building of the clients using the WSDL2WS from that build
> then this is a very useful build verification test e.g.
>
> 1. CVS checkout
> 2. Source build
> 3. Code generation for both client and service (at this point we need the
> WSDL, preferrably stored
> localy) this is a Build verification test (BVT)
>
> If build verification works then test against services.......
> 4. Deploy services
> 5. Run clients
> This is the Regression test
>
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com>
To
> Apache AXIS C Developers List
> 28/08/2004 03:19 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
>
> >
> > When we run a test it would be nice if the wsdl is downloaded into the
> > wsdl folder and generate stubs and then run the test. I guest being
able
> > to download the wsdl implies that the web service is running?.
> >
>
> If we are talking about the automated CVS build test, is it practical to
> assume that the service
> is running?
>
> If you think of the steps.
> 1. CVS checkout
> 2. Source build
> 3. Code generation for both client and service (at this point we need the
> WSDL, preferrably stored
> localy)
> 4. Deploy services
> 5. Run clients
>
> Steps 2-5 would require logging.
>
> Samisa...
>
>
>
> _______________________________
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> http://promotions.yahoo.com/goldrush
>
>
>
RE: Generated source in CVS
Posted by damitha kumarage <da...@opensource.lk>.
Forgive me been so late on commenting on this. But, is not it better if
we coordinate these two, I mean build verification and regression test
into a single test process. This shoud
1 CVS checkout
2 Source build
3 code generation for both client adn service
4 deploy services
5 run clients
thanks
damitha
On Tue, 2004-08-31 at 15:43, John Hawkins wrote:
>
>
> Agreed - we should not mix up build and testing.
> If we use the building of the clients using the WSDL2WS from that build
> then this is a very useful build verification test e.g.
>
> 1. CVS checkout
> 2. Source build
> 3. Code generation for both client and service (at this point we need the
> WSDL, preferrably stored
> localy) this is a Build verification test (BVT)
>
> If build verification works then test against services.......
> 4. Deploy services
> 5. Run clients
> This is the Regression test
>
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 28/08/2004 03:19 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
>
> >
> > When we run a test it would be nice if the wsdl is downloaded into the
> > wsdl folder and generate stubs and then run the test. I guest being able
> > to download the wsdl implies that the web service is running?.
> >
>
> If we are talking about the automated CVS build test, is it practical to
> assume that the service
> is running?
>
> If you think of the steps.
> 1. CVS checkout
> 2. Source build
> 3. Code generation for both client and service (at this point we need the
> WSDL, preferrably stored
> localy)
> 4. Deploy services
> 5. Run clients
>
> Steps 2-5 would require logging.
>
> Samisa...
>
>
>
> _______________________________
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> http://promotions.yahoo.com/goldrush
>
>
>
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
Agreed - we should not mix up build and testing.
If we use the building of the clients using the WSDL2WS from that build
then this is a very useful build verification test e.g.
1. CVS checkout
2. Source build
3. Code generation for both client and service (at this point we need the
WSDL, preferrably stored
localy) this is a Build verification test (BVT)
If build verification works then test against services.......
4. Deploy services
5. Run clients
This is the Regression test
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
28/08/2004 03:19 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
>
> When we run a test it would be nice if the wsdl is downloaded into the
> wsdl folder and generate stubs and then run the test. I guest being able
> to download the wsdl implies that the web service is running?.
>
If we are talking about the automated CVS build test, is it practical to
assume that the service
is running?
If you think of the steps.
1. CVS checkout
2. Source build
3. Code generation for both client and service (at this point we need the
WSDL, preferrably stored
localy)
4. Deploy services
5. Run clients
Steps 2-5 would require logging.
Samisa...
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
>
> When we run a test it would be nice if the wsdl is downloaded into the
> wsdl folder and generate stubs and then run the test. I guest being able
> to download the wsdl implies that the web service is running?.
>
If we are talking about the automated CVS build test, is it practical to assume that the service
is running?
If you think of the steps.
1. CVS checkout
2. Source build
3. Code generation for both client and service (at this point we need the WSDL, preferrably stored
localy)
4. Deploy services
5. Run clients
Steps 2-5 would require logging.
Samisa...
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> OK, I see what you're saying.
>
> Hmm, not sure that this is going to work. As soon as we find a single test
> that we want to add we would then have a choice of either adding it into
> Axis-Java tests (and hence having to write a Java client) or adding it into
> C testsuite. This then turns into an "Axis" test-suite. Which is a good
> idea but not sure that we are ready to do this just yet?
>
> Oh and - do they have the same level of automation in Axis-Java?
>
This is a good point; and I am not sure of. May be we could use our own script.
Samisa...
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 31/08/2004 10:58 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
> Hi John,
> Yes I agree that we have to implement the services in C for testing.
>
> Hence I agree to the fact that we need:
> 1. C clients for all tests.
> 2. C services for all tests
>
> What I was proposing was that if we could align our tests to what we
> already have in Axis Java
> then we could use the Axis Java services for:
> 3. Java services for all tests.
>
> However, if the test scope provided by existing Axis Java tests are not
> sufficient, then it makes
> sense to include code for Java services in our cvs.
>
> Thanks,
> Samisa...
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > Hi Samisa,
> >
> > I'm confused ! I'll repeat and see whether we can understand each other
> ->
> >
> > We need to have C at the server-side because this tests the Axis-C server
> -
> > right?
> > Therefore, using the Axis Java services will not test the Axis-C server -
> > right?
> > Therefore, whatever we do, if we want to test the C server we need to
> > write C services - right?
> > Therefore if you are saying we use the Axis-Java services then we should
> > still right Axis-C services - right?
> >
> > We (Our group not the Axis community) would like to test against non-C
> > services too. This is effectively testing interoperability between a C
> > client and a Java server - something that is good for the Axis C
> community
> > too. Therefore we would like to put all the test services code into CVS
> > (both C and Java). Thus we would have the following in the CVS tree ->
> >
> > C clients for all tests.
> > C services for all tests
> > Java services for all tests.
> >
> > Does this help explain my position?
> >
> > cheers,
> > John.
> >
> >
> >
> >
> >
> >
>
> > Samisa Abeysinghe
>
> > <samisa_abeysingh
>
> > e@yahoo.com>
> To
> > Apache AXIS C Developers List
>
> > 28/08/2004 03:23 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C RE: Generated source in CVS
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > Hi Damitha,
> > >
> > > OK, so we'll go ahead and put our test clients into the autobuild
> process
> > > then as this is independent of the running of the tests.
> > >
> > > re:
> > > >When we run a test it would be nice if the wsdl is downloaded into the
> > > >wsdl folder and generate stubs and then run the test. I guest being
> able
> > > >to download the wsdl implies that the web service is running?.
> > >
> > > Hmm, I think this is not a good idea as it would imply that the build
> had
> > > to be able to see the test suite - a bad dependency.
> > >
> > > I think we should work on the basis that the tests are built using the
> > > wsdl's in CVS and their associated clients are kept in CVS.
> > >
> > > We still have to work out a way to place the server side code into CVS
> in
> > > that case. This is going to invlove a directory structure for c and
> java
> > > services. What do you think - good idea?
> >
> > I proposed to use the same test cases as that of Axis Java to eliminate
> the
> > need of having Java
> > service code in our C++ cvs tree. Is that an acceptable solution? Or do
> we
> > need different services
> > to test againt, other than what is already available with Axis Java?
> >
> > Samisa...
> >
> >
> >
> > >
> > >
> > > John Hawkins
> > >
> > >
> > >
> > >
> > >
> >
> > > damitha@opensourc
> >
> > > e.lk
> >
> > >
> > To
> > > 27/08/2004 11:07 "Apache AXIS C Developers List"
> >
> > > <ax...@ws.apache.org>
> >
> > >
> > cc
>
=== message truncated ===
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
OK, I see what you're saying.
Hmm, not sure that this is going to work. As soon as we find a single test
that we want to add we would then have a choice of either adding it into
Axis-Java tests (and hence having to write a Java client) or adding it into
C testsuite. This then turns into an "Axis" test-suite. Which is a good
idea but not sure that we are ready to do this just yet?
Oh and - do they have the same level of automation in Axis-Java?
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
31/08/2004 10:58 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
Hi John,
Yes I agree that we have to implement the services in C for testing.
Hence I agree to the fact that we need:
1. C clients for all tests.
2. C services for all tests
What I was proposing was that if we could align our tests to what we
already have in Axis Java
then we could use the Axis Java services for:
3. Java services for all tests.
However, if the test scope provided by existing Axis Java tests are not
sufficient, then it makes
sense to include code for Java services in our cvs.
Thanks,
Samisa...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> Hi Samisa,
>
> I'm confused ! I'll repeat and see whether we can understand each other
->
>
> We need to have C at the server-side because this tests the Axis-C server
-
> right?
> Therefore, using the Axis Java services will not test the Axis-C server -
> right?
> Therefore, whatever we do, if we want to test the C server we need to
> write C services - right?
> Therefore if you are saying we use the Axis-Java services then we should
> still right Axis-C services - right?
>
> We (Our group not the Axis community) would like to test against non-C
> services too. This is effectively testing interoperability between a C
> client and a Java server - something that is good for the Axis C
community
> too. Therefore we would like to put all the test services code into CVS
> (both C and Java). Thus we would have the following in the CVS tree ->
>
> C clients for all tests.
> C services for all tests
> Java services for all tests.
>
> Does this help explain my position?
>
> cheers,
> John.
>
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com>
To
> Apache AXIS C Developers List
> 28/08/2004 03:23 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > Hi Damitha,
> >
> > OK, so we'll go ahead and put our test clients into the autobuild
process
> > then as this is independent of the running of the tests.
> >
> > re:
> > >When we run a test it would be nice if the wsdl is downloaded into the
> > >wsdl folder and generate stubs and then run the test. I guest being
able
> > >to download the wsdl implies that the web service is running?.
> >
> > Hmm, I think this is not a good idea as it would imply that the build
had
> > to be able to see the test suite - a bad dependency.
> >
> > I think we should work on the basis that the tests are built using the
> > wsdl's in CVS and their associated clients are kept in CVS.
> >
> > We still have to work out a way to place the server side code into CVS
in
> > that case. This is going to invlove a directory structure for c and
java
> > services. What do you think - good idea?
>
> I proposed to use the same test cases as that of Axis Java to eliminate
the
> need of having Java
> service code in our C++ cvs tree. Is that an acceptable solution? Or do
we
> need different services
> to test againt, other than what is already available with Axis Java?
>
> Samisa...
>
>
>
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
>
> > damitha@opensourc
>
> > e.lk
>
> >
> To
> > 27/08/2004 11:07 "Apache AXIS C Developers List"
>
> > <ax...@ws.apache.org>
>
> >
> cc
> > Please respond to
>
> > "Apache AXIS C
> Subject
> > Developers List" RE: Generated source in CVS
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Hi John,
> > >
> > >
> > >
> > > Hi Folks,
> > >
> > > With regard to auto-build and testing. Could someone explain to me
> about
> > > the server-side a little more.
> > >
> > > Reason for asking: We have a load of tests that are not in CVS but we
> > > would
> > > like to put in. We are holding them out because we do not have C++
> > > services
> > > created for them yet (although some use Calculator most do not) We
are
> > not
> > > going to be able to produce the c services for some time. We do, of
> > > course,
> > > have the java services created for them.
> > >
> > > I don't fully understand the way that the test-suite works in terms
of
> > the
> > > services being available - where is the service code? How is it
> deployed
> > > to
> > > the server?
> >
> > Service code is neither built nor deployed and tested by the test suite
> at
> > the moment.
> >
> > > Although we can add in our clientside wsdls into the autobuild (a
> > valuable
> > > thing to do anyway) we don't want to break the CVS autobuild if there
> are
> > > no services on the server-side so how do you know which tests to run?
> >
> > test suite has no knowledge of what service are deployed and ready to
> serve
> > at the moment.
> >
> > >
> > > If there is somekind of "testrun" script that understands what
services
> > > are
> > > deployed and only attempts to run those then we can add in our client
> > > stubs
> > > today, they can build only, and as the services get created for them
> the
> > > "runtests" script can change too.
> >
> > When we run a test it would be nice if the wsdl is downloaded into the
> > wsdl folder and generate stubs and then run the test. I guest being
able
> > to download the wsdl implies that the web service is running?.
> >
> > thanks
> > damitha
> > >
> > >
> > >
> > >
> > >
> > > "Susantha Kumara"
> > > <susantha@opensou
> > > rce.lk>
> > To
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi John,
Yes I agree that we have to implement the services in C for testing.
Hence I agree to the fact that we need:
1. C clients for all tests.
2. C services for all tests
What I was proposing was that if we could align our tests to what we already have in Axis Java
then we could use the Axis Java services for:
3. Java services for all tests.
However, if the test scope provided by existing Axis Java tests are not sufficient, then it makes
sense to include code for Java services in our cvs.
Thanks,
Samisa...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> Hi Samisa,
>
> I'm confused ! I'll repeat and see whether we can understand each other ->
>
> We need to have C at the server-side because this tests the Axis-C server -
> right?
> Therefore, using the Axis Java services will not test the Axis-C server -
> right?
> Therefore, whatever we do, if we want to test the C server we need to
> write C services - right?
> Therefore if you are saying we use the Axis-Java services then we should
> still right Axis-C services - right?
>
> We (Our group not the Axis community) would like to test against non-C
> services too. This is effectively testing interoperability between a C
> client and a Java server - something that is good for the Axis C community
> too. Therefore we would like to put all the test services code into CVS
> (both C and Java). Thus we would have the following in the CVS tree ->
>
> C clients for all tests.
> C services for all tests
> Java services for all tests.
>
> Does this help explain my position?
>
> cheers,
> John.
>
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 28/08/2004 03:23 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > Hi Damitha,
> >
> > OK, so we'll go ahead and put our test clients into the autobuild process
> > then as this is independent of the running of the tests.
> >
> > re:
> > >When we run a test it would be nice if the wsdl is downloaded into the
> > >wsdl folder and generate stubs and then run the test. I guest being able
> > >to download the wsdl implies that the web service is running?.
> >
> > Hmm, I think this is not a good idea as it would imply that the build had
> > to be able to see the test suite - a bad dependency.
> >
> > I think we should work on the basis that the tests are built using the
> > wsdl's in CVS and their associated clients are kept in CVS.
> >
> > We still have to work out a way to place the server side code into CVS in
> > that case. This is going to invlove a directory structure for c and java
> > services. What do you think - good idea?
>
> I proposed to use the same test cases as that of Axis Java to eliminate the
> need of having Java
> service code in our C++ cvs tree. Is that an acceptable solution? Or do we
> need different services
> to test againt, other than what is already available with Axis Java?
>
> Samisa...
>
>
>
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
>
> > damitha@opensourc
>
> > e.lk
>
> >
> To
> > 27/08/2004 11:07 "Apache AXIS C Developers List"
>
> > <ax...@ws.apache.org>
>
> >
> cc
> > Please respond to
>
> > "Apache AXIS C
> Subject
> > Developers List" RE: Generated source in CVS
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Hi John,
> > >
> > >
> > >
> > > Hi Folks,
> > >
> > > With regard to auto-build and testing. Could someone explain to me
> about
> > > the server-side a little more.
> > >
> > > Reason for asking: We have a load of tests that are not in CVS but we
> > > would
> > > like to put in. We are holding them out because we do not have C++
> > > services
> > > created for them yet (although some use Calculator most do not) We are
> > not
> > > going to be able to produce the c services for some time. We do, of
> > > course,
> > > have the java services created for them.
> > >
> > > I don't fully understand the way that the test-suite works in terms of
> > the
> > > services being available - where is the service code? How is it
> deployed
> > > to
> > > the server?
> >
> > Service code is neither built nor deployed and tested by the test suite
> at
> > the moment.
> >
> > > Although we can add in our clientside wsdls into the autobuild (a
> > valuable
> > > thing to do anyway) we don't want to break the CVS autobuild if there
> are
> > > no services on the server-side so how do you know which tests to run?
> >
> > test suite has no knowledge of what service are deployed and ready to
> serve
> > at the moment.
> >
> > >
> > > If there is somekind of "testrun" script that understands what services
> > > are
> > > deployed and only attempts to run those then we can add in our client
> > > stubs
> > > today, they can build only, and as the services get created for them
> the
> > > "runtests" script can change too.
> >
> > When we run a test it would be nice if the wsdl is downloaded into the
> > wsdl folder and generate stubs and then run the test. I guest being able
> > to download the wsdl implies that the web service is running?.
> >
> > thanks
> > damitha
> > >
> > >
> > >
> > >
> > >
> > > "Susantha Kumara"
> > > <susantha@opensou
> > > rce.lk>
> > To
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Samisa,
I'm confused ! I'll repeat and see whether we can understand each other ->
We need to have C at the server-side because this tests the Axis-C server -
right?
Therefore, using the Axis Java services will not test the Axis-C server -
right?
Therefore, whatever we do, if we want to test the C server we need to
write C services - right?
Therefore if you are saying we use the Axis-Java services then we should
still right Axis-C services - right?
We (Our group not the Axis community) would like to test against non-C
services too. This is effectively testing interoperability between a C
client and a Java server - something that is good for the Axis C community
too. Therefore we would like to put all the test services code into CVS
(both C and Java). Thus we would have the following in the CVS tree ->
C clients for all tests.
C services for all tests
Java services for all tests.
Does this help explain my position?
cheers,
John.
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
28/08/2004 03:23 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> Hi Damitha,
>
> OK, so we'll go ahead and put our test clients into the autobuild process
> then as this is independent of the running of the tests.
>
> re:
> >When we run a test it would be nice if the wsdl is downloaded into the
> >wsdl folder and generate stubs and then run the test. I guest being able
> >to download the wsdl implies that the web service is running?.
>
> Hmm, I think this is not a good idea as it would imply that the build had
> to be able to see the test suite - a bad dependency.
>
> I think we should work on the basis that the tests are built using the
> wsdl's in CVS and their associated clients are kept in CVS.
>
> We still have to work out a way to place the server side code into CVS in
> that case. This is going to invlove a directory structure for c and java
> services. What do you think - good idea?
I proposed to use the same test cases as that of Axis Java to eliminate the
need of having Java
service code in our C++ cvs tree. Is that an acceptable solution? Or do we
need different services
to test againt, other than what is already available with Axis Java?
Samisa...
>
>
> John Hawkins
>
>
>
>
>
> damitha@opensourc
> e.lk
>
To
> 27/08/2004 11:07 "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
>
cc
> Please respond to
> "Apache AXIS C
Subject
> Developers List" RE: Generated source in CVS
>
>
>
>
>
>
>
>
>
>
> Hi John,
> >
> >
> >
> > Hi Folks,
> >
> > With regard to auto-build and testing. Could someone explain to me
about
> > the server-side a little more.
> >
> > Reason for asking: We have a load of tests that are not in CVS but we
> > would
> > like to put in. We are holding them out because we do not have C++
> > services
> > created for them yet (although some use Calculator most do not) We are
> not
> > going to be able to produce the c services for some time. We do, of
> > course,
> > have the java services created for them.
> >
> > I don't fully understand the way that the test-suite works in terms of
> the
> > services being available - where is the service code? How is it
deployed
> > to
> > the server?
>
> Service code is neither built nor deployed and tested by the test suite
at
> the moment.
>
> > Although we can add in our clientside wsdls into the autobuild (a
> valuable
> > thing to do anyway) we don't want to break the CVS autobuild if there
are
> > no services on the server-side so how do you know which tests to run?
>
> test suite has no knowledge of what service are deployed and ready to
serve
> at the moment.
>
> >
> > If there is somekind of "testrun" script that understands what services
> > are
> > deployed and only attempts to run those then we can add in our client
> > stubs
> > today, they can build only, and as the services get created for them
the
> > "runtests" script can change too.
>
> When we run a test it would be nice if the wsdl is downloaded into the
> wsdl folder and generate stubs and then run the test. I guest being able
> to download the wsdl implies that the web service is running?.
>
> thanks
> damitha
> >
> >
> >
> >
> >
> > "Susantha Kumara"
> > <susantha@opensou
> > rce.lk>
> To
> > "'Apache AXIS C Developers
List'"
> > 27/08/2004 05:18 <ax...@ws.apache.org>
> >
> cc
> >
> > Please respond to
> Subject
> > "Apache AXIS C RE: Generated source in CVS
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes we need to have in CVS only the following
> > - The WSDL
> > - Business logic filled server side skeletons
> > - Client side manually written source files that uses the generated
stub
> >
> > And we probably need some changes in the WSDL2Ws tool to say,
> > - Not to generate server side skeletons (so that they don't overwrite
> > files)
> > - Probably to place the generated files in gen_src folders when a
> > command line option --autotest is given.
> >
> > Susantha
> > ---
> >
> >> -----Original Message-----
> >> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> >> Sent: Thursday, August 26, 2004 8:37 PM
> >> To: Apache AXIS C Developers List
> >> Subject: Generated source in CVS
> >>
> >> Hi All,
> >> As we go on building test cases, the CVS is seem to be getting
> > filled
> >> with generated source.
> >> In case of inquire_v2 WSDL (UDDI) this is worse.
> >>
> >> Would it be a good iead to check in only the client (user written)
> >> code, a rerad me and a
> >> chell script to generate the code on to CVS. This will considerably
> > reduce
> >> the time requred to
> >> checkout cvs. We can always generate code locally. (The idea is that
> > the
> >> WSDL tool should always
> >> generate correct code :-))
> >>
> >> Thansk,
> >> Samisa...
> >>
> >>
> >>
> >> _______________________________
> >> Do you Yahoo!?
> >> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> >> http://promotions.yahoo.com/goldrush
> >
> >
> >
> >
> >
>
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
RE: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> Hi Damitha,
>
> OK, so we'll go ahead and put our test clients into the autobuild process
> then as this is independent of the running of the tests.
>
> re:
> >When we run a test it would be nice if the wsdl is downloaded into the
> >wsdl folder and generate stubs and then run the test. I guest being able
> >to download the wsdl implies that the web service is running?.
>
> Hmm, I think this is not a good idea as it would imply that the build had
> to be able to see the test suite - a bad dependency.
>
> I think we should work on the basis that the tests are built using the
> wsdl's in CVS and their associated clients are kept in CVS.
>
> We still have to work out a way to place the server side code into CVS in
> that case. This is going to invlove a directory structure for c and java
> services. What do you think - good idea?
I proposed to use the same test cases as that of Axis Java to eliminate the need of having Java
service code in our C++ cvs tree. Is that an acceptable solution? Or do we need different services
to test againt, other than what is already available with Axis Java?
Samisa...
>
>
> John Hawkins
>
>
>
>
>
> damitha@opensourc
> e.lk
> To
> 27/08/2004 11:07 "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> cc
> Please respond to
> "Apache AXIS C Subject
> Developers List" RE: Generated source in CVS
>
>
>
>
>
>
>
>
>
>
> Hi John,
> >
> >
> >
> > Hi Folks,
> >
> > With regard to auto-build and testing. Could someone explain to me about
> > the server-side a little more.
> >
> > Reason for asking: We have a load of tests that are not in CVS but we
> > would
> > like to put in. We are holding them out because we do not have C++
> > services
> > created for them yet (although some use Calculator most do not) We are
> not
> > going to be able to produce the c services for some time. We do, of
> > course,
> > have the java services created for them.
> >
> > I don't fully understand the way that the test-suite works in terms of
> the
> > services being available - where is the service code? How is it deployed
> > to
> > the server?
>
> Service code is neither built nor deployed and tested by the test suite at
> the moment.
>
> > Although we can add in our clientside wsdls into the autobuild (a
> valuable
> > thing to do anyway) we don't want to break the CVS autobuild if there are
> > no services on the server-side so how do you know which tests to run?
>
> test suite has no knowledge of what service are deployed and ready to serve
> at the moment.
>
> >
> > If there is somekind of "testrun" script that understands what services
> > are
> > deployed and only attempts to run those then we can add in our client
> > stubs
> > today, they can build only, and as the services get created for them the
> > "runtests" script can change too.
>
> When we run a test it would be nice if the wsdl is downloaded into the
> wsdl folder and generate stubs and then run the test. I guest being able
> to download the wsdl implies that the web service is running?.
>
> thanks
> damitha
> >
> >
> >
> >
> >
> > "Susantha Kumara"
> > <susantha@opensou
> > rce.lk>
> To
> > "'Apache AXIS C Developers List'"
> > 27/08/2004 05:18 <ax...@ws.apache.org>
> >
> cc
> >
> > Please respond to
> Subject
> > "Apache AXIS C RE: Generated source in CVS
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes we need to have in CVS only the following
> > - The WSDL
> > - Business logic filled server side skeletons
> > - Client side manually written source files that uses the generated stub
> >
> > And we probably need some changes in the WSDL2Ws tool to say,
> > - Not to generate server side skeletons (so that they don't overwrite
> > files)
> > - Probably to place the generated files in gen_src folders when a
> > command line option --autotest is given.
> >
> > Susantha
> > ---
> >
> >> -----Original Message-----
> >> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> >> Sent: Thursday, August 26, 2004 8:37 PM
> >> To: Apache AXIS C Developers List
> >> Subject: Generated source in CVS
> >>
> >> Hi All,
> >> As we go on building test cases, the CVS is seem to be getting
> > filled
> >> with generated source.
> >> In case of inquire_v2 WSDL (UDDI) this is worse.
> >>
> >> Would it be a good iead to check in only the client (user written)
> >> code, a rerad me and a
> >> chell script to generate the code on to CVS. This will considerably
> > reduce
> >> the time requred to
> >> checkout cvs. We can always generate code locally. (The idea is that
> > the
> >> WSDL tool should always
> >> generate correct code :-))
> >>
> >> Thansk,
> >> Samisa...
> >>
> >>
> >>
> >> _______________________________
> >> Do you Yahoo!?
> >> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> >> http://promotions.yahoo.com/goldrush
> >
> >
> >
> >
> >
>
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Damitha,
OK, so we'll go ahead and put our test clients into the autobuild process
then as this is independent of the running of the tests.
re:
>When we run a test it would be nice if the wsdl is downloaded into the
>wsdl folder and generate stubs and then run the test. I guest being able
>to download the wsdl implies that the web service is running?.
Hmm, I think this is not a good idea as it would imply that the build had
to be able to see the test suite - a bad dependency.
I think we should work on the basis that the tests are built using the
wsdl's in CVS and their associated clients are kept in CVS.
We still have to work out a way to place the server side code into CVS in
that case. This is going to invlove a directory structure for c and java
services. What do you think - good idea?
John Hawkins
damitha@opensourc
e.lk
To
27/08/2004 11:07 "Apache AXIS C Developers List"
<ax...@ws.apache.org>
cc
Please respond to
"Apache AXIS C Subject
Developers List" RE: Generated source in CVS
Hi John,
>
>
>
> Hi Folks,
>
> With regard to auto-build and testing. Could someone explain to me about
> the server-side a little more.
>
> Reason for asking: We have a load of tests that are not in CVS but we
> would
> like to put in. We are holding them out because we do not have C++
> services
> created for them yet (although some use Calculator most do not) We are
not
> going to be able to produce the c services for some time. We do, of
> course,
> have the java services created for them.
>
> I don't fully understand the way that the test-suite works in terms of
the
> services being available - where is the service code? How is it deployed
> to
> the server?
Service code is neither built nor deployed and tested by the test suite at
the moment.
> Although we can add in our clientside wsdls into the autobuild (a
valuable
> thing to do anyway) we don't want to break the CVS autobuild if there are
> no services on the server-side so how do you know which tests to run?
test suite has no knowledge of what service are deployed and ready to serve
at the moment.
>
> If there is somekind of "testrun" script that understands what services
> are
> deployed and only attempts to run those then we can add in our client
> stubs
> today, they can build only, and as the services get created for them the
> "runtests" script can change too.
When we run a test it would be nice if the wsdl is downloaded into the
wsdl folder and generate stubs and then run the test. I guest being able
to download the wsdl implies that the web service is running?.
thanks
damitha
>
>
>
>
>
> "Susantha Kumara"
> <susantha@opensou
> rce.lk>
To
> "'Apache AXIS C Developers List'"
> 27/08/2004 05:18 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
> Yes we need to have in CVS only the following
> - The WSDL
> - Business logic filled server side skeletons
> - Client side manually written source files that uses the generated stub
>
> And we probably need some changes in the WSDL2Ws tool to say,
> - Not to generate server side skeletons (so that they don't overwrite
> files)
> - Probably to place the generated files in gen_src folders when a
> command line option --autotest is given.
>
> Susantha
> ---
>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
>> Sent: Thursday, August 26, 2004 8:37 PM
>> To: Apache AXIS C Developers List
>> Subject: Generated source in CVS
>>
>> Hi All,
>> As we go on building test cases, the CVS is seem to be getting
> filled
>> with generated source.
>> In case of inquire_v2 WSDL (UDDI) this is worse.
>>
>> Would it be a good iead to check in only the client (user written)
>> code, a rerad me and a
>> chell script to generate the code on to CVS. This will considerably
> reduce
>> the time requred to
>> checkout cvs. We can always generate code locally. (The idea is that
> the
>> WSDL tool should always
>> generate correct code :-))
>>
>> Thansk,
>> Samisa...
>>
>>
>>
>> _______________________________
>> Do you Yahoo!?
>> Win 1 of 4,000 free domain names from Yahoo! Enter now.
>> http://promotions.yahoo.com/goldrush
>
>
>
>
>
RE: Generated source in CVS
Posted by da...@opensource.lk.
Hi John,
>
>
>
> Hi Folks,
>
> With regard to auto-build and testing. Could someone explain to me about
> the server-side a little more.
>
> Reason for asking: We have a load of tests that are not in CVS but we
> would
> like to put in. We are holding them out because we do not have C++
> services
> created for them yet (although some use Calculator most do not) We are not
> going to be able to produce the c services for some time. We do, of
> course,
> have the java services created for them.
>
> I don't fully understand the way that the test-suite works in terms of the
> services being available - where is the service code? How is it deployed
> to
> the server?
Service code is neither built nor deployed and tested by the test suite at
the moment.
> Although we can add in our clientside wsdls into the autobuild (a valuable
> thing to do anyway) we don't want to break the CVS autobuild if there are
> no services on the server-side so how do you know which tests to run?
test suite has no knowledge of what service are deployed and ready to serve
at the moment.
>
> If there is somekind of "testrun" script that understands what services
> are
> deployed and only attempts to run those then we can add in our client
> stubs
> today, they can build only, and as the services get created for them the
> "runtests" script can change too.
When we run a test it would be nice if the wsdl is downloaded into the
wsdl folder and generate stubs and then run the test. I guest being able
to download the wsdl implies that the web service is running?.
thanks
damitha
>
>
>
>
>
> "Susantha Kumara"
> <susantha@opensou
> rce.lk> To
> "'Apache AXIS C Developers List'"
> 27/08/2004 05:18 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C RE: Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
> Yes we need to have in CVS only the following
> - The WSDL
> - Business logic filled server side skeletons
> - Client side manually written source files that uses the generated stub
>
> And we probably need some changes in the WSDL2Ws tool to say,
> - Not to generate server side skeletons (so that they don't overwrite
> files)
> - Probably to place the generated files in gen_src folders when a
> command line option --autotest is given.
>
> Susantha
> ---
>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
>> Sent: Thursday, August 26, 2004 8:37 PM
>> To: Apache AXIS C Developers List
>> Subject: Generated source in CVS
>>
>> Hi All,
>> As we go on building test cases, the CVS is seem to be getting
> filled
>> with generated source.
>> In case of inquire_v2 WSDL (UDDI) this is worse.
>>
>> Would it be a good iead to check in only the client (user written)
>> code, a rerad me and a
>> chell script to generate the code on to CVS. This will considerably
> reduce
>> the time requred to
>> checkout cvs. We can always generate code locally. (The idea is that
> the
>> WSDL tool should always
>> generate correct code :-))
>>
>> Thansk,
>> Samisa...
>>
>>
>>
>> _______________________________
>> Do you Yahoo!?
>> Win 1 of 4,000 free domain names from Yahoo! Enter now.
>> http://promotions.yahoo.com/goldrush
>
>
>
>
>
RE: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Folks,
With regard to auto-build and testing. Could someone explain to me about
the server-side a little more.
Reason for asking: We have a load of tests that are not in CVS but we would
like to put in. We are holding them out because we do not have C++ services
created for them yet (although some use Calculator most do not) We are not
going to be able to produce the c services for some time. We do, of course,
have the java services created for them.
I don't fully understand the way that the test-suite works in terms of the
services being available - where is the service code? How is it deployed to
the server?
Although we can add in our clientside wsdls into the autobuild (a valuable
thing to do anyway) we don't want to break the CVS autobuild if there are
no services on the server-side so how do you know which tests to run?
If there is somekind of "testrun" script that understands what services are
deployed and only attempts to run those then we can add in our client stubs
today, they can build only, and as the services get created for them the
"runtests" script can change too.
Thoughts?
John Hawkins
"Susantha Kumara"
<susantha@opensou
rce.lk> To
"'Apache AXIS C Developers List'"
27/08/2004 05:18 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: Generated source in CVS
Developers List"
Yes we need to have in CVS only the following
- The WSDL
- Business logic filled server side skeletons
- Client side manually written source files that uses the generated stub
And we probably need some changes in the WSDL2Ws tool to say,
- Not to generate server side skeletons (so that they don't overwrite
files)
- Probably to place the generated files in gen_src folders when a
command line option --autotest is given.
Susantha
---
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Thursday, August 26, 2004 8:37 PM
> To: Apache AXIS C Developers List
> Subject: Generated source in CVS
>
> Hi All,
> As we go on building test cases, the CVS is seem to be getting
filled
> with generated source.
> In case of inquire_v2 WSDL (UDDI) this is worse.
>
> Would it be a good iead to check in only the client (user written)
> code, a rerad me and a
> chell script to generate the code on to CVS. This will considerably
reduce
> the time requred to
> checkout cvs. We can always generate code locally. (The idea is that
the
> WSDL tool should always
> generate correct code :-))
>
> Thansk,
> Samisa...
>
>
>
> _______________________________
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> http://promotions.yahoo.com/goldrush
RE: Generated source in CVS
Posted by Susantha Kumara <su...@opensource.lk>.
Yes we need to have in CVS only the following
- The WSDL
- Business logic filled server side skeletons
- Client side manually written source files that uses the generated stub
And we probably need some changes in the WSDL2Ws tool to say,
- Not to generate server side skeletons (so that they don't overwrite
files)
- Probably to place the generated files in gen_src folders when a
command line option --autotest is given.
Susantha
---
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Thursday, August 26, 2004 8:37 PM
> To: Apache AXIS C Developers List
> Subject: Generated source in CVS
>
> Hi All,
> As we go on building test cases, the CVS is seem to be getting
filled
> with generated source.
> In case of inquire_v2 WSDL (UDDI) this is worse.
>
> Would it be a good iead to check in only the client (user written)
> code, a rerad me and a
> chell script to generate the code on to CVS. This will considerably
reduce
> the time requred to
> checkout cvs. We can always generate code locally. (The idea is that
the
> WSDL tool should always
> generate correct code :-))
>
> Thansk,
> Samisa...
>
>
>
> _______________________________
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> http://promotions.yahoo.com/goldrush
Re: Generated source in CVS
Posted by Adrian Dick <ad...@uk.ibm.com>.
Hi,
I agree that only the client code should be placed into CVS. As it is
vital the tests always use generated code from the latest WSDL2Ws tooling,
and this is a simple way of forcing the issue - not to mention reducing
clutter and checkout times.
Regards,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
26-08-04 15:36 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Generated source in CVS
Developers List"
Hi All,
As we go on building test cases, the CVS is seem to be getting filled
with generated source.
In case of inquire_v2 WSDL (UDDI) this is worse.
Would it be a good iead to check in only the client (user written)
code, a rerad me and a
chell script to generate the code on to CVS. This will considerably reduce
the time requred to
checkout cvs. We can always generate code locally. (The idea is that the
WSDL tool should always
generate correct code :-))
Thansk,
Samisa...
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
Re: Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Yes, I am talking about those gen_src folders. (both in test and samples)
Ideal solution is to automate the generation during build time.
Samisa...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> In which directory are you talking about? I see a load of directories
> called "gen_src" in tests/client?
>
> I am a little confused as to why we don't just have the one fully automated
> test suite?
>
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 26/08/2004 15:36 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Generated source in CVS
> Developers List"
>
>
>
>
>
>
>
>
>
> Hi All,
> As we go on building test cases, the CVS is seem to be getting filled
> with generated source.
> In case of inquire_v2 WSDL (UDDI) this is worse.
>
> Would it be a good iead to check in only the client (user written)
> code, a rerad me and a
> chell script to generate the code on to CVS. This will considerably reduce
> the time requred to
> checkout cvs. We can always generate code locally. (The idea is that the
> WSDL tool should always
> generate correct code :-))
>
> Thansk,
> Samisa...
>
>
>
> _______________________________
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> http://promotions.yahoo.com/goldrush
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: Generated source in CVS
Posted by John Hawkins <HA...@uk.ibm.com>.
In which directory are you talking about? I see a load of directories
called "gen_src" in tests/client?
I am a little confused as to why we don't just have the one fully automated
test suite?
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
26/08/2004 15:36 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Generated source in CVS
Developers List"
Hi All,
As we go on building test cases, the CVS is seem to be getting filled
with generated source.
In case of inquire_v2 WSDL (UDDI) this is worse.
Would it be a good iead to check in only the client (user written)
code, a rerad me and a
chell script to generate the code on to CVS. This will considerably reduce
the time requred to
checkout cvs. We can always generate code locally. (The idea is that the
WSDL tool should always
generate correct code :-))
Thansk,
Samisa...
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
Generated source in CVS
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi All,
As we go on building test cases, the CVS is seem to be getting filled with generated source.
In case of inquire_v2 WSDL (UDDI) this is worse.
Would it be a good iead to check in only the client (user written) code, a rerad me and a
chell script to generate the code on to CVS. This will considerably reduce the time requred to
checkout cvs. We can always generate code locally. (The idea is that the WSDL tool should always
generate correct code :-))
Thansk,
Samisa...
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush