Open dduportal opened 7 years ago
Do you really need full JRE? I guess that openjdk8-jre-base (aka headless) should be enough.
Hello @jirutka, thanks for this tip.
I tried locally to move to the headless JRE (instead of the JRE), and ended on this error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no fontmanager in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:61)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
at sun.font.SunFontManager$1.run(SunFontManager.java:339)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.SunFontManager.<clinit>(SunFontManager.java:335)
at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:264)
at sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:864)
at net.sourceforge.plantuml.FileFormat$2.calculateDimension(FileFormat.java:99)
at net.sourceforge.plantuml.creole.AtomText.calculateDimension(AtomText.java:144)
at net.sourceforge.plantuml.creole.Sea.add(Sea.java:51)
at net.sourceforge.plantuml.creole.SheetBlock1.initMap(SheetBlock1.java:106)
at net.sourceforge.plantuml.creole.SheetBlock1.calculateDimension(SheetBlock1.java:148)
at net.sourceforge.plantuml.creole.SheetBlock2.calculateDimension(SheetBlock2.java:65)
at net.sourceforge.plantuml.graphic.TextBlockMarged.calculateDimension(TextBlockMarged.java:59)
at net.sourceforge.plantuml.svek.HeaderLayout.getDimension(HeaderLayout.java:65)
at net.sourceforge.plantuml.svek.image.EntityImageClassHeader2.calculateDimension(EntityImageClassHeader2.java:178)
at net.sourceforge.plantuml.svek.image.EntityImageClass.calculateDimension(EntityImageClass.java:97)
at net.sourceforge.plantuml.svek.DotDataImageBuilder.printEntity(DotDataImageBuilder.java:277)
at net.sourceforge.plantuml.svek.DotDataImageBuilder.printEntities(DotDataImageBuilder.java:268)
at net.sourceforge.plantuml.svek.DotDataImageBuilder.buildImage(DotDataImageBuilder.java:138)
at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFileInternal(CucaDiagramFileMakerSvek.java:99)
at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFile(CucaDiagramFileMakerSvek.java:65)
at net.sourceforge.plantuml.cucadiagram.CucaDiagram.exportDiagramInternal(CucaDiagram.java:334)
at net.sourceforge.plantuml.classdiagram.ClassDiagram.exportDiagramInternal(ClassDiagram.java:202)
at net.sourceforge.plantuml.UmlDiagram.exportDiagramNow(UmlDiagram.java:231)
at net.sourceforge.plantuml.AbstractPSystem.exportDiagram(AbstractPSystem.java:129)
at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:149)
at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:121)
at org.asciidoctor.diagram.plantuml.PlantUML.generate(PlantUML.java:105)
at org.asciidoctor.diagram.CommandProcessor.processRequest(CommandProcessor.java:40)
at org.asciidoctor.diagram.CommandServer.processRequests(CommandServer.java:58)
at org.asciidoctor.diagram.CommandServer.main(CommandServer.java:25)
asciidoctor-diagram: ERROR: Failed to generate image: end of file reached
I tried to explicitly install fontconfig
and ttf-dejavu
but it was not solving the stack. I did not try much more to be honest.
For information, the size gain was ~3 Mb based on the docker image ls
command output (435 Mb instead of 438 Mb).
I guess the suggestion of a smaller "base" image in #54 relates to this issue also?
Bumping this since the size increased _significantly from ~250MB (1.2) to ~440MB (1.3) as listed on DockerHub; local docker images
lists them as ~470MB and ~1.5GB (!!), respectively.
From a user perspective after reading the changelog, it's completely unclear to me where this increase comes from.
After analysis, it seems the increase is fully due to #166 :
Seems to be that a feature some might need shouldn't have this much of a size impact, but that's of course for the maintainers to trade off.
Guess: Cleaning out cabal caches and removing all the dev packages again should decrease the image size dramatically. Recommendation: For dependency-heavy compilations of which we only want the result in the final file, I can recommend multi-stage builds.
Thanks @reitzig for pointing the fact that #166 added a 1 Gb size penalty 😱.
If you have any knowledge on the cabal package system, it could be a great help to have a contribution. Would you be up for the challenge?
There is an opportunity here to contribute to Alpine Linux by adding a native erd
package.
We can also revert #166 time to find a viable solution in term of size, WDYT?
@reitzig I started https://github.com/asciidoctor/docker-asciidoctor/pull/175 : feel free to use it, push to it, etc.
If you have any knowledge on the cabal package system, it could be a great help to have a contribution. Would you be up for the challenge?
Not really. I've used cabal to install pandoc before and blew up my backup in the process, so that's what triggered me here.
I'll see if I can quickly fix the Dockerfile
; I won't be able to do any testing, though. (Are there automated tests of any form?)
After #39, #46 and #47 have increased the size of the image (protip: I might be the person responsible on this by missing knowledge on Ruby Gems / Native Alpine Package).
Helped has been asked in #47 on this, and we might be able to improve this in the future.
I propose that we first implement a CD process where logs are available with testing harness (cf proposal in #49 ) before jumping on this topic.
What would be your thoughts @mojavelinux @jirutka and the community?
[EDIT] The size increased was caused by the "return" of the JRE OpenJDK 8 installation in #46