Indeed this XSL file includes another one from SourceForge. I've filed https://github.com/pressgang/pressgang-tools/issues/3 to replace it with a local copy. Not sure how that stuff works internally, probably one would have to unpack the DockBook dependency and refer to its XSL files locally.
2015-07-21 21:47 GMT+02:00 Hardy Ferentschik <ha...@hibernate.org>: > Hi, > > just attempted a full built of ORM and got this as part of the > documentation build: > > Error at xsl:import on line 4 of > jar:file:/Users/hardy/.gradle/caches/modules-2/files-2.1/org.jboss.pressgang/pressgang-xslt-ns/3.0.0/d98c5f6ef7d69dd33a3ad45656f6640100e8fc82/pressgang-xslt-ns-3.0.0.jar!/xslt/org/jboss/pressgang/xhtml.xsl: > Failure reading > http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl: Server > returned HTTP response code: 503 for URL: > http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl > Error at xsl:if on line 14 of > file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl: > Variable img.src.path has not been declared > Error at xsl:value-of on line 15 of > file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl: > Variable img.src.path has not been declared > :documentation:renderDocBook_devguide_en-US_html FAILED > > Looks like another problem with external dtd/xsl verification. Probably > nothing we have direct control over. Just wanted to give the heads up. > AFAIK Sourceforge is still having problems after their major meltdown. I > am still not able to upload the Validator release. > > --Hardy > > On Mon, Jul 20, 2015 at 03:55:16PM +0200, Gunnar Morling wrote: > > Ah yes; I had pulled, that's why I couldn't reproduce this issue locally > :) > > Thanks for fixing it! > > > > 2015-07-20 14:13 GMT+02:00 Steve Ebersole <st...@hibernate.org>: > > > > > Pull again :) I fixed this yesterday. We were missing the SourceForge > > > url for local resolution of the CFG DTD > > > > > > On Mon, Jul 20, 2015, 3:30 AM Gunnar Morling <gun...@hibernate.org> > wrote: > > > > > >> Hi, > > >> > > >> I noticed an interesting failure of HibernateCacheTest from the > > >> "hibernate-ehcache" module in a recent ORM CI build [1]. > > >> > > >> It failed to obtain hibernate-configuration-3.0.dtd from SourceForge > > >> (there > > >> was some service outage at SF at this time). Apart from the fact that > the > > >> test uses the legacy URL (I'll fix that), I am wondering why the > config > > >> parser tried to obtain the DTD remotely in the first place. We have > > >> LocalXmlResourceResolver in place which is there to prevent this. An > > >> indeed > > >> if I debug the test locally, I don't get to the place where it would > > >> download it from remote. > > >> > > >> Anyone with an idea why that would happen on CI? > > >> > > >> Thanks, > > >> > > >> --Gunnar > > >> > > >> [1] > > >> > > >> > http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/ > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
