I fixed the issue by copying the definition of xml:space into the IF schema.
See http://svn.apache.org/viewvc?rev=1304524&view=rev Vincent On 24/02/12 15:29, Vincent Hennebert wrote: > On 16/02/12 10:23, mehdi houshmand wrote: >> 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. > > ‘ant setup-xml-schema’ does that for you and you should have to run it only > once per local copy. > > >> 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? > > I’m facing the same issue and it’s certainly suboptimal. I’m still unsure > about the proper way to solve it though. > > >> 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... > > I investigated the issue again some time ago and couldn’t reach any definite > conclusion. > > AFAICT the XML schema is published under the W3C Document License, due to the > absence of explicit notice and as per [1]. I don’t think it’s covered by the > W3C Software License because that would allow to modify the schema and would > kill the purpose of the standard (the ‘interoperability problems’ mentioned in > [1]). > > ATM and AFAICT, it’s unclear whether we are allowed to publish material under > the W3C Document License. I’ve been watching the two following legal issues on > JIRA but they haven’t been resolved yet: > https://issues.apache.org/jira/browse/LEGAL-109 > https://issues.apache.org/jira/browse/LEGAL-111 > > At any rate, ATM we don’t comply with the requirements prescribed by the W3C > Document License [2]. Yet we have a copy of xml.xsd in > src/documentation/intermediate-format-ng. I think we cannot release FOP until > this has been resolved. > > As for a solution, the simplest probably is to rewrite the part of the XML > schema that is of interest to us. This may be as simple as rewriting the > definition of xml:space, but I haven’t tested it. > > [1] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#Which > [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 > > > Vincent > > >> 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 >>>>>