+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"
<[email protected]>
|
|
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.
|
- RE: backing up customised ant configuration Samisa Abeysinghe
-
