Go you beauty! ... Bernhard and i corresponded offlist over his JUnit tests for the Catalog Resolver. The tests proved that his mods to CommandlineContext.java worked and we can both now build docs.
So people on both Win* and *nix platforms should be free of this blocker bug. You should be able to: 1) use the sample "Entity Catalogs" from the Welcome page 2) run "build docs" and get past "catalog-test.xml" 3) run "build test" and pass the Catalog Resolver tests. Bernhard Huber wrote: > David Crossley wrote: > >Thanks Bernhard, setting fork="yes" in build.xml was the trick. > >The test cases now run for me. > > great > > >Hooray, there were no errors reported and the ResolverImpl > >testcase seemed to be resolving its entities properly. > >It seems that all is OK now for Win and Linux. > > that's good news > > >So will you now proceed to make the necessary changes to > >ResolverImpl.java proper? > > no, that's already, to fix bug 5060, as far as I think. As Bug 5060 > only appeared in "build docs", changing CommandlineContext > only is enough. As it returnde some strange URL for its getResource() > method. I see now. I mistakenly thought that some subsequent changes would be needed to ResolverImpl. Yes, the key thing was to get a reliable absolute path from getResource() ... i think that you have probably squashed a bug that had wider implications than just CatalogResolver. > Try running build docs including the catalog-test in book.xml! > <menu label="Tests"> > <menu-item label="Catalog Test" href="catalog-test.html"/> > </menu> > > It should work now! It does for me on Linux and i gather so too for you on Win. > ResolverImpl is okay, you may discuss adding in dispose() releasing the > CatalogResolver, but that should happen anyway. > > For short I was thinking files like ISOnum.pen are not released, as I > was unable to delete the temporarily test file ISOnum.pen which is > created in directory specified by java.io.tempdir. > But closing the InputStream, respectivly Reader in the testX() method, > solved that. This is interesting. I just assumed that the parser was taking care of that. The parser called the resolveEntity() method to get the alternative local InputSource. If that returned null, then it would need to open its own source as specified by the original systemIdentifier declared in the XML instance document. I expected that the parser would close the stream in both circumstances. > I hope you enjoyed running the test, I "dream" adding more testcases. It > should help to make Cocoon more stable, and help it to add more grazy > features without loosing the wonderful features already available. > > bye bernhard The test case method a was brilliant way to prove that your solution worked. I gather that we will leave these testcases in place and refine them to become a testing tool for the local site manager. --David Crossley --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
