Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]

2012-03-23 Thread Vincent Hennebert
I fixed the issue by copying the definition of xml:space into the IF
schema.

See http://svn.apache.org/viewvc?rev=1304524view=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 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 +, 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 

Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]

2012-03-23 Thread mehdi houshmand
Yaaayy!! Thanks Vincent. Much appreciated!

Mehdi

On 23 March 2012 17:40, Vincent Hennebert vhenneb...@gmail.com wrote:

 I fixed the issue by copying the definition of xml:space into the IF
 schema.

 See http://svn.apache.org/viewvc?rev=1304524view=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 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 +, Jeremias Maerki wrote:
  To whom it may engage...
 
  This is an 

Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]

2012-02-24 Thread Vincent Hennebert
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 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 +, 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:
 - 

Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]

2012-02-16 Thread mehdi houshmand
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 +, 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]

2011-11-10 Thread Vincent Hennebert
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