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
> >
> >
> >
>
>