Won't work on Windows or OS X though. Macs have a /usr/share/java, but there's nothing useful in it.

On Mon, Jul 1, 2019 at 7:39 AM Peter Stadler <pstadler@mail.uni-paderborn.de> wrote:
In general, I’d say that this is a standard component which should be provided by the respective base system, not by our repository.
For the Docker image, we should provide a way to make this available to ant. A rather simple approach would be to symlink /usr/share/java  to ~/.ant/lib. (I just tried and `ant -diagnostics` shows it works)

Best
Peter

> Am 01.07.2019 um 13:03 schrieb Hugh Cayless <philomousos@gmail.com>:
>
> Can we depend on the resolver being in /usr/share/java on every system though? I'd have thought not.
>
> I suspect the Jenkins Docker build does a not-altogether-standard install of OpenJDK 8, meaning not everything is where ant might expect to find it.
>
> On Mon, Jul 1, 2019 at 6:07 AM Peter Stadler <pstadler@mail.uni-paderborn.de> wrote:
> tools.jar shouldn’t be an issue because although being in a different place it’s in the java classpath.
> The resolver.jar indeed is not. It’s installed as xml-resolver-1.2.jar under /usr/share/java/ which is not in the java classpath.
>
> Rather than adding this jar to our Utilities folder (which is already cluttered with external libraries) I’d prefer to fix the Docker image by adding  /usr/share/java/ to the java classpath globally.
>
> Best
> Peter
>
> > Am 30.06.2019 um 17:50 schrieb Hugh Cayless <philomousos@gmail.com>:
> >
> > Just trying out the Jenkins Docker, and indeed, tools.jar is not in /usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar, but it *is* in /usr/local/openjdk-8/lib/, so something funky is going on with that...
> >
> > On Sun, Jun 30, 2019 at 11:19 AM Hugh Cayless <philomousos@gmail.com> wrote:
> > The Jenkins Docker build should have a proper JDK installed automatically, but maybe it's not where ant thinks it should be?
> >
> > On Sun, Jun 30, 2019 at 11:07 AM Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
> > 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
> > _______________________________________________
> > 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
>