Hi Marina, Michael and Tom
I would like to name the CVS-managed sample test.properties "
sample-test.properties" rather than "default-db.properties" because it can
contain other properties other than db properties and it's just sample. And
I will delete the "test.properties" in CVS.
With regard to ${glassfish.home}, I think it's well known (probably
described in build instruction page) property in glassfish workspace. Also
user may change it (or glassfish.root) in ~/build.properties then it's more
adaptable for such change. So I would like to remain it.
If you all agree with this, I will apply this(with updated readme.txt).
Cheers,
-Wonseok
On 12/21/06, Marina Vatkina < Marina.Vatkina_at_sun.com> wrote:
>
> 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
> >>> >
> >>> >
> >>> >
> >>>
> >>>
>