Re: backing up customised ant configuration

[sanjaya singharage]

I think there is no harm in keeping the backup ant script since it acts alone. The properties can be used without any hindrance.   sanjaya. ----- Original Message ----- From: Samisa Abeysinghe To: Apache AXIS C Developers List Sent: Wednesday, March 30, 2005 9:24 AM Subject: RE: backing up customised ant configuration +1 for property based system. That is much clean. What we could do is to improve the server side test scripts properties more. (These improvements should ideally be done in 1.6)   Thanks, Samisa�   -----Original Message----- From: John Hawkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 29, 2005 7:42 PM To: Apache AXIS C Developers List Subject: Re: backing up customised ant configuration   +1 for using the current property based system where we can Adrian Dick/UK/[EMAIL PROTECTED] 29/03/2005 14:26 Please respond to "Apache AXIS C Developers List" To "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org> cc   Subject Re: backing up customised ant configuration   Hi, This all sounds good. I have few comments below on things that can be done for client-side testing which can help avoid this problem.  I haven't (yet) tried the server-side testing, so am uncertain if it can do the same. Regards, Adrian _______________________________________ Adrian Dick ([EMAIL PROTECTED]) "sanjaya singharage" <[EMAIL PROTECTED]> wrote on 29/03/2005 13:38:19: > A small ant script backupconf.xml is now created so that testers can back-up > and restore locally modified ant configurations. The targets are backup and > restore. > > What is backed up is... > 1. the server.wsdd.PLATFORM for the ant service framework Are these not generated "on-the-fly" by the ant framework? As is done when testing client-side handlers. > 2. build.PLATFORM.properties An alternative is to use -Ddir.properties=<my dir with my version of build.PLATFORM.properties> > 3. The client side test XMLs You can specify -Dtest.list=<location my test.list file> which is simply a test file with an entry for each desired <test>.xml to be used, instead of having to delete those you're currently not interested in. > 4. The services XMLs Perhaps a similar system could be used here as in step 3.