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

[Vincent Hennebert <vh...@gmail.com>]

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 general@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]

[mehdi houshmand <me...@gmail.com>]

Yaaayy!! Thanks Vincent. Much appreciated!

Mehdi

On 23 March 2012 17:40, Vincent Hennebert <vh...@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=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 <vh...@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 general@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]

[Vincent Hennebert <vh...@gmail.com>]

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 <vh...@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 general@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]

[Vincent Hennebert <vh...@gmail.com>]

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 <vh...@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 general@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]

[mehdi houshmand <me...@gmail.com>]

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 <vh...@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 general@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
>>>