axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From damitha kumarage <dami...@opensource.lk>
Subject RE: Generated source in CVS
Date Fri, 03 Sep 2004 06:32:44 GMT
On Fri, 2004-09-03 at 11:36, Samisa Abeysinghe wrote:
> --- damitha kumarage <damitha@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 <damitha@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          <axis-c-dev@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
> 


Mime
View raw message