On Dec 21, 2006, at 11:26 AM, Wonseok Kim wrote:
> On 12/22/06, Craig L Russell <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> 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!
- application/pkcs7-signature attachment: smime.p7s