[BUILDS] Getting to the bottom of Nightly Trunk Disaster

[Lewis John Mcgibbney <le...@gmail.com>]

Houston, we have a problem...
Failing tests are as follows
- Full list [0]
- org.apache.any23.Any23Test.testDemoCodeSnippet2 [1]
- org.apache.any23.extractor.html.HListingExtractorTest.testKelkoo [2]
- org.apache.any23.extractor.html.HListingExtractorTest.testKelkooFull [3]
- org.apache.any23.vocab.RDFSchemaUtilsTest.testSerializeVocabulariesNTriples
[4]
- org.apache.any23.vocab.RDFSchemaUtilsTest.testSerializeVocabulariesRDFXML
[5]
- org.apache.any23.cli.MicrodataParserTest.testRunOnHTTPResource [6]
- org.apache.any23.Any23Test.testGZippedContent [7]

I've made the following observations.

   - [1], [7] as well as testXMLMimeTypeManagementViaURL() and
   testBlankNodesViaURL() are all from Any23Test and (in the patch I'm
   currently cooking up for ANY23-140 [8]) should be dealt with as follows:
   All documents used within the tests should be stored in
   'apache-any23-test-resources' module and pushed as static content to a
   local Jetty server to simulate HTTP aspects of testing. The Jetty server
   can be setUp() before the tests and used then destroyed.
   - [2] and [3] I actually have no clue about at all. I don't know when
   these tests started to fail. What I see from the stack traces is that
   triples such as the one below cause trouble for the extractor.

   Cannot find triple (null
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
http://sindice.com/hlisting/0.1/Item)

   - [4] and [5] began to fail after I committed ANY23-142 [9]. We are now
   (whether correct or not) extracting far more triples than hardcorded into
   the assertions for these tests. Can someone please explain in more detail
   what RDFSchemaUtilsTest is actually doing. Also if we currently test
   NTriples and RDF/XML, why don't we test NQuads?
   - In [6] I suppose the document currently available @ [10] should also
   be available as static content available within the same Jetty testing
   server started and used in other tests above.

We have one other major problem though, when the build checks out the Any23
trunk code, it seems to build modules numerous times. Peter mentioned in
the past that this was to do with the Maven Invoker Plugin, but I am
struggling to find the configuration within the parent pom.xml...

Finally, by checking the build logs, it appeared that the build was timing
out @45 mins (this is very long!... No?) but I increased it anyway to 90
mins in an attempt to get a successful but unstable build.

It would be really NICE to get the build sorted out as it has been quite a
while and is a blocker IMHO for us to release.


Lewis

[0] *http://s.apache.org/ad3*
[1] *http://s.apache.org/No8*
[2] *http://s.apache.org/yB*
[3] *http://s.apache.org/tcZ*
[4] *http://s.apache.org/NzU*
[5] *http://s.apache.org/e0I*
[6] *http://s.apache.org/cBw*
[7] *http://s.apache.org/f6R*
[8] https://issues.apache.org/jira/browse/ANY23-140
[9] https://issues.apache.org/jira/browse/ANY23-140
[10] http://www.imdb.com/title/tt1375666/<http://www.imdb.com/title/tt1375666/%5D>
*Lewis*