[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Windows Port (Ant test script on Linux) - Status Update
|
Jonathan,
Per my previous note, I've just posted a new set of scripts, etc. as a
Bugzilla attachment.
(These are not patches, but complete files).
Please see embedded comments --
At 08:01 AM 4/30/2003, Jonathan Gossage wrote:
See embedded comments
----- Original Message -----
From: "Jim Wright - IBM Research" <jwright@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Sent: Tuesday, April 29, 2003 5:21 PM
Subject: [stellation-res] Windows Port (Ant test script on Linux) - Status
Update
> Jonathan,
>
> Yesterday, I finished testing on Windows (local and remote tests both
worked)
> and moved on to Linux/PostgreSQL tests.
>
> Unfortuately, the org.eclipse.stellation.core/test/build.xml file
> has a number of issues on Linux:
> * a number of targets that should run only once were running
> multiple times
> * There seem to be an excess of properties (e.g. both username.postgres
> and username.firebird); my preference is to have such properties set
> via a properties file (e.g. a single 'username' property, set to
> postgres or
> firebird username as required for a given test configuration)
The intent here was to be able to extend the test script to run against
multiple databases, one at a time
in a single run. I guess we could restructure this to provide a set of
database specific property files and use those as the triggers to determine
which databases the tests are run against. Do you want me to do this
restructuring?
Please take a look at the scripts I just posted, and then let's consider
what's actually needed.
My current thinking is to use multiple copies of the
stellation.test.properties file, one for each
database/mode combination. These might be kept underneath the
${user.home}/stellation directory.
For example,
...stellation/firebird.local/stellation.test.properties,
...stellation/firebird.remote/stellation.test.properties,
...stellation/postgres.local/stellation.test.properties,
...stellation/postgres.remote/stellation.test.properties,
Then, just copy the desired test setup into .../stellation and proceed.
I'm not sure that supporting tests of multiple databases in a single run is
necessarily a good idea -- particularly since remote-mode testing requires
some external work
(e.g. "ant force-init; runserver; ant").
Thoughts?
<snip>
> (Also - I need to fix the build-core.xml clean-install target, since it
> quietly blows
> away everything in usr/local/bin, a distinctly unfriendly act.)
Fixing this fully is non-trivial since you basically need to know what you
installed there the last time you put things in it. It is problems like this
that drive the need for proper installer programs. Perhaps the temporary fix
is to not try and remove our previous stuff automatically.
I've made a small change, to only delete the scripts (in install-clean)
which would
have been installed there using the install-server target in the same script.
Pretty crude, but relatively safe (although it can't handle changes in the set
of installed scripts).
As you said, the real solution is a proper installer program; the current
workaround is
primarily intended for convenience during Stellation development.
Regards,
Jim
--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
