How to make jlatexmath available for plantuml?
jobasto opened this issue · 10 comments
This issue is related to #45. Plantuml can use JLatexMath to render math formulas (see http://plantuml.com/ascii-math). If one uses the standalone plantuml version the JLatexMath *.jar files have to be added to the same folder the plantuml.jar resides in. I've verified that this works. I tried the same with the eclipse plantuml, i.e. I copied the JLatexMath *.jar files into eclipse\configuration\org.eclipse.osgi\590\0.cp\lib where also the platnuml-epl-1.2018.9.jar file can be found.
However, that doesn't solve the problem. I'm getting the same error message that was described in #45 (see below).
If I understand the message correctly eclipse can't load the generated image file, probably because it was never generated. But I only see the loading error exception but not the exception that is thrown by plantuml when it tries to generate the image. Is there a way to see that exception trace? The standalone plantuml return the following message when it can't find JLatexMath: (see bottom)
Is there a way to tell the eclipse plantuml to use the classes exported by the JLatexMath .jar files?
Regarding the license: the current JLatexMath uses GPL with a linking exception. So I hope that you could include it in your package. I would also be fine to install it by myself if I just knew how to do it.
Exception thrown by standalone plantuml:
formula=ax^2+bx+c=0
Latex={a}{x}^{{2}}+{b}{x}+{c}={0}
java.lang.ClassNotFoundException: org.scilab.forge.jlatexmath.TeXFormula
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at net.sourceforge.plantuml.math.TeXIconBuilder.(TeXIconBuilder.java:53)
at net.sourceforge.plantuml.math.LatexBuilder.buildIcon(LatexBuilder.java:66)
at net.sourceforge.plantuml.math.LatexBuilder.getImage(LatexBuilder.java:82)
at net.sourceforge.plantuml.math.AsciiMath.getImage(AsciiMath.java:106)
at net.sourceforge.plantuml.math.ScientificEquationSafe.getImage(ScientificEquationSafe.java:112)
at net.sourceforge.plantuml.creole.AtomMath.drawU(AtomMath.java:102)
at net.sourceforge.plantuml.creole.SheetBlock1.drawU(SheetBlock1.java:170)
at net.sourceforge.plantuml.creole.SheetBlock2.drawU(SheetBlock2.java:77)
at net.sourceforge.plantuml.skin.rose.ComponentRoseArrow.drawInternalU(ComponentRoseArrow.java:164)
at net.sourceforge.plantuml.skin.AbstractComponent.drawU(AbstractComponent.java:74)
at net.sourceforge.plantuml.sequencediagram.graphic.MessageArrow.drawInternalU(MessageArrow.java:142)
at net.sourceforge.plantuml.sequencediagram.graphic.GraphicalElement.drawU(GraphicalElement.java:60)
at net.sourceforge.plantuml.sequencediagram.graphic.DrawableSet.drawPlaygroundU(DrawableSet.java:337)
at net.sourceforge.plantuml.sequencediagram.graphic.DrawableSet.drawU22(DrawableSet.java:262)
at net.sourceforge.plantuml.sequencediagram.graphic.SequenceDiagramFileMakerPuma2$1.drawU(SequenceDiagramFileMakerPuma2.java:214)
at net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageInternal(ImageBuilder.java:254)
at net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageTOBEMOVED(ImageBuilder.java:178)
at net.sourceforge.plantuml.sequencediagram.graphic.SequenceDiagramFileMakerPuma2.createOne(SequenceDiagramFileMakerPuma2.java:235)
at net.sourceforge.plantuml.sequencediagram.SequenceDiagram.exportDiagramInternal(SequenceDiagram.java:249)
at net.sourceforge.plantuml.UmlDiagram.exportDiagramNow(UmlDiagram.java:227)
at net.sourceforge.plantuml.AbstractPSystem.exportDiagram(AbstractPSystem.java:135)
at net.sourceforge.plantuml.PSystemUtils.exportDiagramsSequence(PSystemUtils.java:204)
at net.sourceforge.plantuml.PSystemUtils.exportDiagrams(PSystemUtils.java:89)
at net.sourceforge.plantuml.SourceFileReaderAbstract.getGeneratedImages(SourceFileReaderAbstract.java:153)
at net.sourceforge.plantuml.Run.manageFileInternal(Run.java:493)
at net.sourceforge.plantuml.Run.processArgs(Run.java:398)
at net.sourceforge.plantuml.Run.manageAllFiles(Run.java:367)
at net.sourceforge.plantuml.Run.main(Run.java:189)
Error message shown in eclipse plantuml
It's really a license issue.
Maybe you can write to JLatexMath team to ensure that they are ok that theirs jar is distributed either by PlantUML or by the Eclipse Plugin, even if this plugin is distributed under EPL.
If they agree, we could probably make it work.
In their current license file they state:
Linking this library statically or dynamically with other modules
is making a combined work based on this library. Thus, the terms
and conditions of the GNU General Public License cover the whole
combination.
But they have the following addition:
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce
an executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under terms
of your choice, provided that you also meet, for each linked independent
module, the terms and conditions of the license of that module.
An independent module is a module which is not derived from or based
on this library. If you modify this library, you may extend this exception
to your version of the library, but you are not obliged to do so.
If you do not wish to do so, delete this exception statement from your
version.
Wouldn't that allow you to include their *.jar file? However, I haven't tried their current version yet. I've used the one offered on http://plantuml.com/ascii-math and when that version was released they didn't have the linking exception in their license file.
License issues aside: Can I put the files from http://plantuml.com/ascii-math somewhere where the eclipse plantuml will find and use them?
Please see the following response: opencollab/jlatexmath#49 (comment)
So if I understand this correctly, we're allowed to include the jlatexmath jar in the plantuml plugin (together with the plantuml.jar)?
That is my understanding when I read the cited documents carefully (without being a lawyer), yes.
OK, I've added it to the next milestone (1.1.24).
I know I am late to the game, but I would like to add the perspective of someone developing an Eclipse project.
The Eclipse foundation has very strict requirements on which licenses can be used for Eclipse projects. These requirements are, in some cases, even stricter than what you would expect if you follow the latter of the law, just to make sure that the Eclipse code base is allowed to stay EPL licensed. This means that we have to make a big detour around any infectious licenses.
What this means in practice that for each dependency that we use, we need to file a request that is then evaluated by the IP team. They do check for contagious licenses and prohibit including a dependency if they feel like this might run counter to Eclipse's guidelines.
Combining EPL and GPL works is always tricky. A large part of the EPLv2 FAQ is dedicated to this topic. I am not an expert (neither are the folks discussing the issue linked above), but I would at least be cautious to assume that we would be allowed to continue to use plantuml in our Eclipse project if it included parts that are GPL licensed.
My suggestion would be to run this by the Eclipse IP team before including this library in the next version of plantuml. What do you think?
@steghoja You mean when your project depends on PlantUML you might have stricter license requirements than PlantUML has (in isolation)? That's a good point! In that case we would need two variants of the core plantuml.lib plugin, on with and one without the jlatexmath dependency. Perhaps it is possible to include the jlatextmath library as a fragment, that extends the core library's class path, to avoid this issue. Then the fragment would not be depended on, but could be installed separately? I'll have to check if this is technically possible.
Well, technically you could say the IP due diligence process at the Eclipse foundation makes sure that your license is actually valid and does not get overriden by something else. They might be overcautious, but at least you can be sure that your stuff is actually licensed the way it's supposed to be.
I am sure you remember that you used to have cs.jar (which was LGPL licensed) as part of the project and that someone from Eclipse got in touch with you about that a while ago. That was because I had filed a request for them to investigate the license situation for your work. Eclipse was okay to use the PlantUML Eclipse Plugin as long as that jar wasn't included. If you add another jar that is GPL (or similar, even without exception), that might mean that we could no longer use your work in Eclipse Capra.
As long as we can get a version of your work from your update site that does not include anything that is not licensed according to the Eclipse foundation rules, we should be fine.
I've a solution that works no, where you can install the jlatex support separately.