harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)
Date Mon, 27 Feb 2006 03:12:51 GMT


Tim Ellison wrote:
> I'd echo those sentiments.
> 
> Geir: how close are you to putting HARMONY-57 to the vote?

I think I have everything, but fear the JIRA!  Fear the JIRA! :)


> 
> Regards,
> Tim
> 
> George Harley wrote:
>> Just want to emphasise something that has possibly got lost in this
>> thread. To date, all of the discussion on this topic seems to have been
>> based on "eye balling" of the code in issue HARMONY-57. It would almost
>> certainly help move things forward if people were to start actually
>> running the tests (particularly those pesky java.net.* ones).
>>
>> Once people start running these tests we can discuss experiences of
>> set-up etc and work to *evolve* them into something more suitable to the
>> needs of the Harmony development community. It's only natural that
>> improvements in test coverage, test quality and test
>> complexity/simplicity are going to occur. The simpler it is to set up
>> and run the tests, the better for all of us. My own comments on this
>> thread have been mainly focussed about what is actually there *today* in
>> HARMONY-57 ; it would be great to move up to discussions on the running
>> tests and then for us all to participate in their evolution.
>>
>> My 2 Euro Cents.
>>
>> George
>> IBM UK
>>
>>
>>
>> George Harley wrote:
>>> Mark Hindess wrote:
>>>> I think it might help this disagreement if we step back and decide
>>>> what scenarios for running tests we are trying to optimise.
>>>>   
>>> Disagreement ? What ? On this mailing list ? :-)
>>>
>>>> Personally, whenever I write tests I'm doing it to optimise the
>>>> scenario where a new users comes to the project and does:
>>>>
>>>> 1$ svn co ... classlib # or wget/tar if you prefer
>>>> 2$ cd classlib/make
>>>> 3$ ant test
>>>>
>>>> I do this because I want the tests to be easy to run by new users
>>>> particularly on new platforms.  I hope making it this easy means we
>>>> get more people running tests and that we get a broader set of results
>>>> than we could acheive ourselves.
>>>>
>>>> This scenario becomes slightly less pleasant if, between steps 2 and
>>>> 3, [*] you have to find your nearest Linux machine and install Apache
>>>> httpd, your-favourite-ftp-server, Dante socks server, etc.  This
>>>> typically means that I'd be inclined to write stub servers to test
>>>> against.
>>>>
>>>> But this doesn't mean George is wrong!  Because *if* there was a
>>>> publically accessible Internet server that already had Apache httpd,
>>>> twoftpd (my favourite ftp server this week), Dante socks, etc, then
>>>> the scenario I like to optimise becomes possible.  The effort of
>>>> setting up one hosting server is definitely cheaper than the effort of
>>>> implementing stubs - I know because I set up the server George tests
>>>> against and it didn't take much time at all.
>>>>   
>>> Agreed : a central, publicly available test server that could be used
>>> for network-related testing would IMHO be advantageous to us all. I
>>> wonder if such a server can be supplied through the auspices of the
>>> ASF ? Incidentally, it took me only a small amount of time to set up
>>> my laptop for running the tests on locally.
>>>
>>>> Having one server means we wont get 1000's of users asking Apache
>>>> httpd, twoftpd, Dante socks configuration questions on our mailing
>>>> lists.  It also means we have a way to see the other half of the
>>>> results - that is, the server logs.  (Stubs should make this easier
>>>> and this cost should be considered too but if we ran the server we
>>>> could make this easier.)
>>>>
>>>> George's approach continues to be cheaper even if a few groups have to
>>>> set up there own servers - though I think the set of users who "don't
>>>> have Internet access but do have a mechanism for getting up to date
>>>> Harmony code" should be small and getting smaller.  Of course, it
>>>> becomes much more expensive if everyone has to do it.
>>>>   
>>> Agreed.
>>>
>>>> I've never tried using George's approach on past projects because I've
>>>> either also been writing server code, that can/should be used by
>>>> tests, or because the server was massive and I didn't have the
>>>> experience or resources to run a real server.  Because of this,
>>>> initially, I was inclined to support the implemention of stubs, but
>>>> now I'm not so certain.
>>>>
>>>> I think it basically comes down to whether or not we can provide a
>>>> central server.  I'm not sure it's a simple question but for me this
>>>> question is key to this issue.
>>>>
>>>> Or perhaps I'm optimising for the wrong scenario?
>>>>
>>>> Regards,
>>>>  Mark.
>>>>
>>>> [*] More likely people would run step 3 find it goes horribly wrong
>>>>     then read the README they ignored initially and discover why. ;-)
>>>>
>>>>   
>>>
>>
> 

Mime
View raw message