Hi Michael,
I replied in the morning but my mozilla browser crashed when I sent
the reply, so please ignore one of the replies, if there are two ;).
I like your idea about adding a test.properties= setting to the
~/build.properties file, and renaming the test.properties to be
default-db.properties. We'd also need to replace all wording about
editing the file with the opposite (not edit, but copy, replace, reference, etc.).
There is one more problem with the current version of the test.properties: it
uses ${glassfish.home} variable that is not documented, and does not need
to be set otherwise. Can it be defaulted to ../../publish/glassfish instead?
thanks,
-marina
Michael Bouschen wrote On 12/20/06 07:11,:
> Hi Marina, hi Wonseok,
>
> I do not have a problem with test.properties being checked in. The
> current settings in test.properties use JavaDB database properties and
> they should work w/o any changes. I prefer creating a new properties
> file (instead of editing test.properties) for any database settings that
> are specific for my environment. This properties file is not under cvs
> control. Is it an idea to rename the file (not the property)
> test.properties to default-db.properties to make clear that this file
> defines the default?
>
> I tried setting the property test.properties in ~/build.properties and
> it works! So after adding the following line to my ~/build.properties file
> test.properties=oracle.properties
> a call 'ant test' uses the database settings from the local
> oracle.properties file. This is equivalent to calling 'ant
> -Dtest.properties=oracle.properties' test'.
>
> Regards Michael
>
>
>>Hi Wonseok,
>>
>>Wonseok Kim wrote:
>>
>>>Hi Marina,
>>>
>>>On 12/20/06, *Marina Vatkina* < Marina.Vatkina_at_sun.com
>>><mailto:Marina.Vatkina_at_sun.com>> wrote:
>>>
>>> Hi Wonseok,
>>>
>>> Is test.properties checked in into cvs? If yes, it is a problem as
>>> we'll be
>>> accidentally overriding it all the time (this was the reason to
>>> introduce
>>> ~/build.properties option).
>>>
>>>
>>>Yes it's checked in. Do you mean that it should not be managed by CVS
>>>because it can be changed for each environment?
>>
>>Yes. This is exactly my concern.
>>
>>
>>>Hmm, then do you think that something like test.properties.template
>>>should be checked in?
>>
>>This is an option. Another option would be to set "test.properties"
>>property to ~/build.properties (will it work?).
>>
>>>Currently if we don't want to edit this file directly, using
>>>-Dtest.properties option or setting test.properties property in
>>>~/build.properties with another properties file can be option.
>>
>>It would be nice if you don't need to use -D option by default.
>>
>>
>>>Do you have better idea?
>>
>>I listed mine. May be somebody else has a better one?
>>
>>thanks,
>>-marina
>>
>>
>>>Thanks,
>>>-Wonseok
>>>
>>> thanks,
>>> -marina
>>>
>>> Wonseok Kim wrote:
>>> > Hi All,
>>> > Please note that entity-persistence-tests environment is updated
>>> as the
>>> > following message.
>>> >
>>> > Everyone who modified build.properties should move your target
>>> database
>>> > properties from build.properties file to test.properties
>>>file(which
>>> > contains JavaDB(Derby) properties by default), or you can make
>>> another
>>> > properties file as explained below(or see updated readme.txt).
>>> >
>>> > Please let me know if you have problem.
>>> >
>>> > Thanks,
>>> > -Wonseok
>>> >
>>> > On 12/18/06, *Wonseok Kim* <guruwons_at_gmail.com
>>> <mailto:guruwons_at_gmail.com>
>>> > <mailto:guruwons_at_gmail.com <mailto:guruwons_at_gmail.com>>> wrote:
>>> >
>>> >
>>> > * Run test with another DB properties without rebuilding
>>> > Database properties are separated from build.properties and
>>> stored
>>> > in test.properties file.
>>> > We can modify the test.properties file directly or use
>>>another
>>> > properties file by -Dtest.properties option for ant.
>>> >
>>> > This makes really easy to run test on different databases.
>>> > For example if we would like to run test with another
>>>database
>>> > properties, do as follows:
>>> > $ ant -Dtest.properties=derby.properties test //test
>>>on Derby
>>> > $ ant -Dtest.properties=oracle.properties test //test on
>>> Oracle
>>> >
>>> > To make this possible the properties file is read from
>>>testing
>>> > framework(JUnitTestCase) in runtime and they override the
>>> properties
>>> > which is passed to creatEntityManagerFactory(pu,
>>>properties).
>>> > So we don't need to put these properties in
>>>persistence.xml files
>>> > and replace it in build time, it is done now in runtime. "ant
>>> build"
>>> > is not any more dependent on properties file, so it doesn't
>>> need to
>>> > rebuild for another database properties.
>>> >
>>> > I put derby database properties in test.properties for
>>>default
>>> > configuration.
>>> > This makes beginners quick to run test out of the box with
>>> bundled
>>> > JavaDB.
>>> >
>>> > * Run a single test class
>>> > To run a single test class, -Dtest.class option can be used.
>>> >
>>> > For example,
>>> > $ ant
>>> >
>>>-Dtest.class=oracle.toplink.essentials.testing.tests.ejb.ejbqltesting.JUnitEJBQLDateTimeTestSuite
>>>
>>>
>>> > test
>>> >
>>> > * Log level without modifying persistence.xml files
>>> > test.properties file can contain toplink.logging.level
>>> property and
>>> > this will override the persistence.xml property.
>>> > This is handy in debugging case.
>>> >
>>> > The junit ant task in build.xml now contains maxmemory="256m"
>>> > because it threw OutOfMemoryError if log level is FINEST.
>>> >
>>> > I think that this patch is useful for others as well as for
>>> me. What
>>> > do you think?
>>> >
>>> > Regards,
>>> > -Wonseok
>>> >
>>> >
>>> >
>>>
>>>