Opinions on adding new -D option to test-project cmd line

[Greg Monroe <Gr...@DukeCE.com>]

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
5843B903F59D4C8C6806BB49A3911901E92738@dukece-mail3.dukece.com%3e
 
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 <Mo...@DukeCE.com> (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.

Re: Opinions on adding new -D option to test-project cmd line

[Thomas Fischer <tf...@apache.org>]

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
> 5843B903F59D4C8C6806BB49A3911901E92738@dukece-mail3.dukece.com%3e
>
> 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 <Mo...@DukeCE.com> (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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org