Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
Yaaayy!! Thanks Vincent. Much appreciated! Mehdi On 23 March 2012 17:40, Vincent Hennebert wrote: > 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-2620#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 > 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 poin
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
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-2620#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 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 +, Jeremias Maerki wrote: > To whom it may engage... > > This is an automated request, but not an un
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
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-2620#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 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 +, 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 th
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
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 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 +, 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 >>>
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
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 +, 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 >>