Out of the 2, #1 seems better.
Please add a note about the ${glassfish.home} into the readme file - while it's
mentioned in GF pages, there is nothing so far that depends on it (may be it's
defaulted somewhere if it's not set).
thanks,
-marina
Wonseok Kim wrote:
> 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
> <mailto: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>
> >> <mailto: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>
> >>>> <mailto: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
> <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
> <mailto:Craig.Russell_at_sun.com>
> >
> > P.S. A good JDO? O, Gasp!
> >
> >
>
>