I'm not sure what to think here. Personally, I do not like the "extends"
logic in the test project at all. The reason why it is needed is that I
do not know any other way to get the db specific driver into the maven
classpath.
The problem with the -D entry and the extends clause is the very cryptic
error message you get if you do not specify the property properly. And I
do not see how the extends path helps to iterate over different settings.
The driver issue does not exist in the different environments here, so I
do not think another extends path entry is necessary. In fact, I'd feel
more comfortable with a simple ant script which e.g. invokes the command
line "maven -D...." and puts in other property files each time it runs.
Maybe the other properties can also be set via -D. No idea if that is
possible, it is just a crazy idea.
But you have thought more about this than I have, so if you think it is
the best possible solution it's fine with me.
In all cases, I would not put too much effort in it. I am going to propose
to switch the build process to maven 2 in the 4.0-SNAPSHOT branch shortly,
and if that's accepted, this will not be reusable in maven 2.
Thomas
On Mon, 27 Nov 2006, Greg Monroe wrote:
I've been working on a modification to the Test-project
run scripts to make it easier to test with the various
option combinations. See:
http://mail-archives.apache.org/mod_mbox/db-torque-dev/200611.mbox/%3c8F
[EMAIL PROTECTED]
Before I get too far into working on this, I thought I'd
poll folks to see if the basic design is OK.
The goal here is to be able to do test runs using a
combination of locally defined DB settings (e.g., the
existing profiles) and a set of pre-defined Torque
Generation options. This way you just define your
local test DB info once. Then run the test-project
against the combinations of options sets you need.
The best way to do this is to expand on how the
existing test-project uses <extends> tags in it's
project.xml file to work. E.g., all test runs require
the command line option:
-Dtorque.test.profile=<db>
which causes the <db> profile's project.properties to be
added to the test-project's project.properties.
The change I'm proposing (and have a proof of principal
version done), is to modify the <extents> chain so that
the test-project extends a generation option set which
extends the db profile set. This means doing a test run
would now require a command line with an additional
option. E.g.:
maven -Dtorque.test.profile=mysql -Dtorque.test.options=db-test1
Where db-test1 is be a directory located under a
run-options directory (like the profile directory)
containing a project.properties file with a set of
Torque generation options and a simple project.xml file.
The reason to do it this way is that project.properties
are immutable, i.e. once set they can not be changed. So,
having the run options low in the extends chain ensures
you are testing what you think you are and not some leftover
settings in a local DB profile.
I'm planning on created the sets needed to do all the
option combination specified in the dev e-mail referenced
(plus documentations, etc).
For quick development testing, this should be a minor
change. Just update whatever method you use in testing
mods to include your favorite option set(s). (FWIW,
the two db specific tests described probably cover 80-90%
of possible problems). If you have a personal favorite set
of options, just create your own run-options directory.
To validate a patch with the SVN head, just check out
a sandbox version of torque, apply the patch, copy in
your local db profiles, and run the appropriate set
of tests. This would be very easy to script the run
process (and maybe eventually do a results roll up).
Thoughts? Other ways to do this? Enhancements? etc.
Greg
Greg Monroe <[EMAIL PROTECTED]> (919)680-5050
C&IS Solutions Team Lead
Duke Corporate Education, Inc.
333 Liggett St.
Durham, NC 27701
Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are
confidential communication or may otherwise be privileged or confidential and
are intended solely for the individual or entity to whom they are addressed.
If you are not the intended recipient you may not rely on the contents of this
email or any attachments, and we ask that you please not read, copy or
retransmit this communication, but reply to the sender and destroy the email,
its contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is strictly
prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
