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 >>>>
