Installing open-jdk-8-jdk got rid of those messages for me (on ancient version of ubuntu)


On 30/06/2019 15:53, Hugh Cayless wrote:
I see the following message in the logs: "Unable to locate tools.jar.
Expected to find it in /usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar" I
think that means the JDK isn't installed, or isn't completely installed?


On Sun, Jun 30, 2019 at 10:45 AM Hugh Cayless <philomousos@gmail.com> wrote:

It's still failing on Jenkins though...not sure why. It's still giving the
"Warning: XML resolver not found; external catalogs will be ignored"
message, which I no longer get locally, so I'm guessing it's not seeing, or
is failing to deal with, the resolver-1.2.0.jar library.

On Sun, Jun 30, 2019 at 10:25 AM Lou Burnard <lou.burnard@retired.ox.ac.uk>
wrote:

Thanks Hugh. With those changes, it works fine for me too. Someone should
remember to tell Luis not to bother, all the same!
On 30/06/2019 14:45, Hugh Cayless wrote:

I've had a go at fixing this by adding an XML catalog for the RNGs in
Exemplars, and (incidentally) fixing that dratted warning about the missing
resolver by adding one. It builds successfully for me locally. We'll see if
it works for Jenkins...

Hugh

On Sun, Jun 30, 2019 at 7:22 AM Lou Burnard <lou.burnard@retired.ox.ac.uk> <lou.burnard@retired.ox.ac.uk>
wrote:


The real question is: why are we including this file via an HTTP copy from
the TEI website, when it's already present in the Exemplums directory? A
gnomic comment in the ODD source suggests this is something to do with
oXGarage:

line 70:

 <moduleRef xmlns="http://www.tei-c.org/ns/1.0" <http://www.tei-c.org/ns/1.0><http://www.tei-c.org/ns/1.0> <http://www.tei-c.org/ns/1.0> xmlns:rng="http://relaxng.org/ns/structure/1.0" <http://relaxng.org/ns/structure/1.0><http://relaxng.org/ns/structure/1.0> <http://relaxng.org/ns/structure/1.0> url="https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng" <https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng><https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng> <https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng>>
<!-- this needs to be an absolute URI to keep oxGarage happy -->

(This is for the inclusion of SVG rng, but the same applies, presumably,
to the inclusion of mathml.rng)

But

(a) is this still really true? is the new oxGarage less demanding? Peter?

(b) even if it is true, wouldn't it be better to point to a website run by
the people who run SVG and Mathml (respectively) assuming there is such a
thing?

The copy in the Exemplum directory is exactly the same as the one I just
downloaded from the TEI website. Since the former has been languishing
there for THIRTEEN YEARS,  it's not the most dynamic of data in any case...

It seems to me it would be better to try to work within the constraints of
having a professionally maintained secure website than bend the rules. I
assume Luis set this limit for a purpose, and I'd rather trust his judgment
if possible!
On 30/06/2019 05:31, Martin Holmes wrote:

I think I was wrong about this: the server error is 429, which is "too
many requests". I think the tei server may be set up to reject repeated
requests for the same files, which is something the build process does as a
matter of course. I've written to Luis to ask if there's a limit, and if
so, whether it can be lifted.

[xslt]
/var/lib/jenkins/jobs/Stylesheets-dev/lastSuccessful/archive/dist/xml/tei/stylesheet/odds/teiodds.xsl:1236:20:
Fatal Error! I/O error reported by XML parser processinghttps://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng:
Server returned HTTP response code: 429 for URL:https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng
Cause: java.io.IOException: Server returned HTTP response code: 429 for
URL: https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/svg11.rng

Cheers,
Martin

On 2019-06-29 3:16 p.m., Martin Holmes wrote:

I think this is caused by the fact that the tei-c.org server is not
serving some files correctly. If you wget that URL, you'll see that you get
a 301 redirect to google.com. I've reported this to Luis, but if I
understand his response correctly, it's some sort of security measure he
put in place. I've asked him if he can change the setup so that files like
rng are served appropriately as text/xml, and he agreed to look at it.

Cheers,
Martin

On 2019-06-29 1:43 p.m., Lou Burnard wrote:


Well, the build is now a lot healthier. The new validation method which
checks examples against the schema being documented, rather than TEI All as
before threw up a number of bugs in the source of the simplePrint odd. So
not all change is bad!

The Make still fails though: now with a message the meaning of which
defeats me: Anyone got any idea what's going on here?

BUILD FAILED
/home/lou/Public/TEI/P5/Test/antruntest.xml:147: Fatal error during
transformation using
/usr/share/xml/tei/stylesheet/profiles/tei/relaxng/to.xsl: I/O error
reported by XML parser processinghttps://www.tei-c.org/release/xml/tei/Exemplars/mathml2-qname-1.mod.rng:
Server returned HTTP response code: 429 for URL:https://www.tei-c.org/release/xml/tei/Exemplars/mathml2-qname-1.mod.rng;
SystemID: file:/usr/share/xml/tei/stylesheet/odds/teiodds.xsl; Line#:
1292; Column#: 21

Total time: 9 seconds
Makefile:54: recipe for target 'tei_allPlus.special' failed
make: *** [tei_allPlus.special] Error 1

I can live happily without tei_allPlus.special tbh.


On 29/06/2019 21:32, Martin Holmes wrote:

Hi Lou,

Our main objective was to try to get the build working ahead of the
release, not to say that what was done in the simplePrint ODD was wrong. I
think you're right that there's something broken in the Stylesheets that
wasn't broken before, but all our attempts to figure that out have failed
so far. You're very welcome to help with that, and I really wish you would,
rather than shouting at people.

Cheers,
Martin

On 2019-06-29 8:50 a.m., Lou Burnard wrote:

Thinking about this debacle again, it seems to me that the approach taken
in issue #370 (oh tei_simpleprint.odd has stopped working: so there must be
something wrong with it) is really not defensible.

1. The unmodified tei_simplePrint odd is structured in exactly the same
way as countless other ODDs, not excluding the TEI Guidelines. It has free
floating globs of specification elements, which are invoked from a single
schemaSpec by means of specGrpRefs.

2. The only thing which is slightly different about it is that some
objects are declared more than once in multiple specGrps, with
@mode=change. This is because the specGrps are organised thematically (for
example one contains changes needed to introduce processing models, another
contains changes needed to introduce schematron rules). This kind of
logical organisation is perfectly reasonable as far as I am aware, indeed
why else bother to have specGrps.

3. The only objection I can see to it is that an ODD processor has to
decide how to combine two or more @mode=change specs. It's not just a
matter of applying one set of changes: there may be a bunch of them. This
is kind of the way unification grammars work in NLP: you build up the
complete spec one bit at a time. Yes, occasionally you may find
contradictions -- one spec adds an attribute x (say) which another one
deletes, or gives a different datatype to.  But this is not the only place
where ODD processing is underspecified and rules of thumb are not hard to
imagine (e.g. delete always wins; in the absence of delete, most recent
modification always wins; etc.).

4. Moreover, and this is where I am really a bit annoyed, THIS USED TO
WORK! So some infrastructural change has made it impossible to run the
makefile and impossible to use the simpleprint odd as originally designed.
And instead of trying to find what change has caused this, we are shooting
the messenger. This my friends is called zealotry. In the immortal words of
Michael SpMcQ in another recent context, "please don't".






_______________________________________________
Tei-council mailing listTei-council@lists.tei-c.orghttp://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________
Tei-council mailing listTei-council@lists.tei-c.orghttp://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________
Tei-council mailing listTei-council@lists.tei-c.orghttp://lists.lists.tei-c.org/mailman/listinfo/tei-council


_______________________________________________
Tei-council mailing listTei-council@lists.tei-c.orghttp://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council


      

      
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council