persistence@glassfish.java.net

Re: entity-persistence-tests update

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Tue, 02 Jan 2007 13:20:11 -0800

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!
>
>