Hi Marina,
On 12/20/06, Marina Vatkina <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?
Hmm, then do you think that something like test.properties.template should
be checked in?
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.
Do you have better idea?
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 >> 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
> >
> >
> >
>