Happy New Year!
I think there are two resolutions here. Let me know if there is another
remaining issue.
1. Leave test.properties as it is (managed by CVS) for running test out of
the box and recommend using -D option or ~/build.properties if you want
another database properties. Then we just need to add this recommendation in
readme.txt.
2. Don't manage test.properties by CVS and add 'sample-test.properties' with
'setup' Ant target which makes default test.properties from the sample file.
This will make people modify test.properties freely without concening
version control (of course they can also use -D or ~/build.properties).
Craig, Michael seem to prefer #1. Marina and other members, which do you
prefer?
Thanks,
-Wonseok
On 1/3/07, Marina Vatkina <Marina.Vatkina_at_sun.com> wrote:
>
> Happy New Year everybody!
>
> Wonseok,
>
> Is this issue still under discussion?
>
> thanks,
> -marina
>
> Craig L Russell wrote:
> >
> > On Dec 21, 2006, at 11:26 AM, Wonseok Kim wrote:
> >
> >> On 12/22/06, *Craig L Russell* <Craig.Russell_at_sun.com
> >> <mailto:Craig.Russell_at_sun.com>> wrote:
> >>
> >>
> >> On Dec 21, 2006, at 9:36 AM, Michael Bouschen wrote:
> >>
> >>> Hi Wonseok,
> >>>
> >>>> Hi Michael,
> >>>>
> >>>> On 12/22/06, *Michael Bouschen* < Michael.Bouschen_at_sun.com
> >>>> <mailto: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.properties should be used if test.properties
> >>>> doesn't exist?
> >>>>
> >>> the issue I see is that it does not run out of the box, because
> >>> build.xml defaults to a file that does not exists in the cvs
> >>> repository. If I check out a fresh entity-persistence-test
> >>> directory, I first need to manually copy sample-test.properties
> >>> to test.properties before I can run the tests.
> >>
> >>
> >> I don't like this at all. I think the tests should run out of the
> >> box with the default database and default settings. One of the
> >> worst experiences for a new developer on a project is to have to
> >> comb through lots of info just to get stuff to work, and
> >> deliberately making it difficult is a bad idea.
> >>
> >>
> >> Then, how about making a new ant target like "ant setup" which
> >> generates test.properties file from the sample-test.properties. This
> >> adds one more step to run test at first time, but readme.txt will
> >> explain this clearly. So new developers can run test on JavaDB without
> >> modifying properties.
> >
> >
> > I guess I'd prefer that we not add complexity to the process by
> > requiring another ant setup to be performed.
> >
> > What is the objection to having the checked-in test.properties file be
> > configured with a correctly set up test run? You can modify the
> > ~/build.xml (not under version control) to refer to the configuration
> > file you want to test with if it's not the default.
> >
> >> It also allows us to modify it directly without concerning version
> >> control.
> >
> >
> > I would recommend that anyone who wants a configuration different from
> > the checked-in version to use ~/build.xml to refer to their modified
> > version and not update the standard default version. The only reason to
> > modify the standard default version is to update the defaults, not to
> > add local changes applicable only to the developer.
> >
> > Craig
> >
> >>
> >> What do you think?
> >
> >>
> >>> For me the checked in properties file serves two purposes:
> >>> - it defines the default properties that work w/o changes
> >>> - it is a sample I can use to create a properties file with my
> >>> database settings
> >>> I would prefer that build.xml refers the file that is checked in.
> >>> There is still no need to edit this file, because in my
> >>> ~/build.xml I can default to a different file that is not under
> >>> version control.
> >>
> >>
> >> I like this idea.
> >>
> >> Craig
> >>
> >>>
> >>> What do you think?
> >>>
> >>> Regards Michael
> >>>
> >>> [snip]
> >>
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> >> 408 276-5638 mailto:Craig.Russell_at_sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> >>
> >
> > Craig Russell
> >
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> >
> > 408 276-5638 mailto:Craig.Russell_at_sun.com
> >
> > P.S. A good JDO? O, Gasp!
> >
> >
>