persistence@glassfish.java.net

Re: entity-persistence-tests update

From: Wonseok Kim <guruwons_at_gmail.com>
Date: Fri, 22 Dec 2006 01:53:31 +0900

Hi Michael,

On 12/22/06, Michael Bouschen <Michael.Bouschen_at_sun.com> wrote:
>
> Hi Wonseok,
>
> 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.
>
> Using the name sample-test.properties sounds good to me. Are you planning
> to change the build.xml and default the property test.property to
> sample-test.properties?
> <property name="test.properties" location="./sample-test.properties"/>
>

My idea was just that sample-test.properties which is managed in repository
is just sample and users should make test.properties by copying it. So
build.xml should remain as it is. Do you mean that
sample-test.propertiesshould be used if
test.properties doesn't exist?

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.
>
> I agree, ${glassfish.home}is a known property and it is described in the
> build instructions:
> http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=BuildInformation. It
> defaults to ${glassfish.root}/publish/glassfish, so there is no need to
> explicitly set it. But it is possible to install the glassfish image into a
> different directory and then you want to set it in ~/build.properties. In
> this case the sample-test.properties would still work.
>
>
> If you all agree with this, I will apply this(with updated readme.txt).
>
> Sounds good!
>
> Regards Michael
>
>
> 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.propertiesand
> > >>> 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
> > >>> >
> > >>> >
> > >>> >
> > >>>
> > >>>
> >
>
>
>