- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 16 Oct 2007 14:55:09 +0100
- To: "Sean Owen" <srowen@google.com>, "Miguel Garcia" <miguel.garcia@fundacionctic.org>
- Cc: "public-mobileok-checker" <public-mobileok-checker@w3.org>
> -----Original Message----- > From: public-mobileok-checker-request@w3.org [mailto:public-mobileok- > checker-request@w3.org] On Behalf Of Sean Owen > Sent: 16 October 2007 14:50 > To: Miguel Garcia > Cc: public-mobileok-checker > Subject: Re: Bug 508 fix and more about CatalogResolver > > > What was the change to commons-httpclient-3.1.jar, anyone know? I had > put in the final 3.1 release a few days ago and want to make sure we > use that. Mea culpa I found I had updated and ended up with an "ascii" version, which after a couple of seconds messing around and hosing on the server I thought I should replace with a fresh copy. > > Several tests seem to fail now due to changes in counting of > whitespace? Measures #1 also fails because a CSS file is no longer > invalid. These may be fine and the test results can be regenerated but > I wanted to check. In general it's good to check in changes to the > tests too with changes to the code. > > On 10/16/07, Miguel Garcia <miguel.garcia@fundacionctic.org> wrote: > > We find that CatalogResolber wasn't running properly because mobile > > checker was downloading the DTDs files in order to do grammar > > validation. We discover that in the CatalogManager.properties file the > > catalogs property, which refers to the catalog.xml file, had an absolute > > path. We have changed it to a relative path and commited the file, > > please ensure that now is working properly particularly in non-Windows > > SO. > > Ack, that is my fault. I accidentally committed this change during > testing to make sure the relative vs. absolute path was not the issue. > Thank you for fixing it. > > But, now it seems like the DTDs are being retrieved remotely for me > again. I will have to investigate. > > > We think this jar could be lighten (is about 7.5Mb) by removing tomcat > > and junit classes because they are not needed as junit test files are > > not included, or is this a slip and junit test are expected to be in the > > jar file? > > You're right, I have just checked in a change to not include these. > > > For the moment we can't release until the above is resolved but it is > close. A couple of moki comments coming in a following mail. Jo
Received on Tuesday, 16 October 2007 13:55:49 UTC