Hi, I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and found it extremely frustrating that the schema (xml.xsd) had to be in the same folder as the test class?!?! Why? It means, if I want to run said test with the Eclipse Junit Runner, I have to copy it into the proper directory, manually. In related news, when I run "ant junit", it chokes every time for a minute on checking the cached xsd file. I mean, it's obviously not the end of the world, but it is annoying and I'm questioning if it's necessary?
Gump fails, periodically because of this same issue, which is annoying at best, and quite dangerous since false positives on a CI server... I don't need to preach to the choir here. Can we not assume that the normal W3C software license [1] applies here? If not, their document license [2]? If so, as per the Apache legal recommendations [3], we're thumbs up for distributing this file (with the notice). If either of those assumptions aren't valid, I'd be happy to ask the Apache legal team, they can at least resolve the ambiguity about the license. Just wanted to know your thoughts? This has been bugging me for a while... Mehdi [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.html [3] http://www.apache.org/legal/resolved.html#category-a On 10 November 2011 12:20, Vincent Hennebert <vhenneb...@gmail.com> wrote: > On 10/11/11 09:31, Simon Pepping wrote: >> It is not a good idea to fetch xml.xsd from W3C each time. Put it in >> the sources and if necessary use a catalog. xml.xsd is already >> available at src/documentation/intermediate-format-ng/xml.xsd. > > Hmmm. Apparently Gump deletes the workspace directory before every > build, which pretty much kills the benefits of the caching process that > I had put in place in rev. 1186858. > > FWIW, I did have in mind to use a catalog, but AFAICT the catalog-based > resolver available from XML Commons Resolver is not compatible with what > is used by XML Schema (org.w3c.dom.ls.LSResourceResolver vs > org.xml.sax.EntityResolver or javax.xml.transform.URIResolver). Also, > using a catalog seemed a bit overkill for this. > > Storing xml.xsd locally is an option, but: > • we lose the link to http://www.w3.org/2001/xml.xsd (although I suppose > we can say that it’s obvious from looking at the content of the file) > • if the original schema ever gets updated, we get out of sync (although > I suppose that’s unlikely to happen) > • most of all, are we allowed to redistribute this file? I couldn’t find > any license information with it. > > For those reasons I chose to download it into some cache directory. > I could remove this caching mechanism and point to > src/documentation/intermediate-format-ng/xml.xsd instead, if bullet 3 > above is not an issue. > > Thoughts? > Thanks, > Vincent > > >> Simon >> >> On Thu, Nov 10, 2011 at 08:27:53AM +0000, Jeremias Maerki wrote: >>> To whom it may engage... >>> >>> This is an automated request, but not an unsolicited one. For >>> more information please visit http://gump.apache.org/nagged.html, >>> and/or contact the folk at gene...@gump.apache.org. >>> >>> Project xml-fop-test has an issue affecting its community integration. >>> This issue affects 1 projects, >>> and has been outstanding for 61 runs. >>> The current state of this project is 'Failed', with reason 'Build Failed'. >>> For reference only, the following projects are affected by this: >>> - xml-fop-test : XSL-FO (Formatting Objects) processor >>> >>> >>> Full details are available at: >>> http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html >>> >>> That said, some information snippets are provided here. >>> >>> The following annotations (debug/informational/warning/error messages) were >>> provided: >>> -INFO- Failed with reason build failed >>> -INFO- Project Reports in: >>> /srv/gump/public/workspace/xml-fop/build/test-reports >>>
