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"/>
>
> 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
> <mailto: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>
> >>><mailto: 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>>
> >>> > <mailto: 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
> >>> >
> >>> >
> >>> >
> >>>
> >>>
>
>