Re: 9.5: coping with loss of ditaa.jar
Tim Cross writes: > Another alternative which I just found is the ditaa version on github, > which has SVG support. See https://github.com/stathissideris/ditaa. If > you click on the 'release' link on the right, there is the most recent > release, which includes a link to a standalone ditaa.jar file. > > I've not tried this version, but suspect it will work fine (assuming > they use semantic versioning, which indicates the API has not > changed). > > > Perfect! Thank you for pointing that out. I downloaded that, installed java-11-openjdk from the Fedora repos and tried the standard example: --8<---cut here---start->8--- #+begin_src ditaa :file example.svg :results file drawer ++ +---++---+ || --+ ditaa +--> | | | Text | +---+|diagram| |Document| |!magic!|| | | {d}| | || | +---++ +---++---+ : ^ | Lots of work | +-+ #+end_src #+RESULTS: :results: [[file:example.svg]] :end: --8<---cut here---end--->8--- It worked perfectly on Fedora 34. Thanks! -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: 9.5: coping with loss of ditaa.jar
Greetings Tim. Tim Cross writes: > I think you missed one obvious solution - donwload the jar file from > the ditaa project homepage on sourceforge. > Another alternative which I just found is the ditaa version on github, > which has SVG support. See https://github.com/stathissideris/ditaa. If > you click on the 'release' link on the right, there is the most recent > release, which includes a link to a standalone ditaa.jar file. Ok, so at least two different standalone versions seem to be available: 1. via "project page" on sourceforge; looking inside the downloaded zip, this seems to be version 0.9 2. via developer github page, version 0.11. On the github page there is a discussion indicating that a clojure version will _not_ be forthcoming after all. The author also states that (s)he is no longer interested in maintaining ditaa: https://github.com/stathissideris/ditaa/issues/69 > I don't think you need to be paranoid about downloading the jar file > from the project homepage - either you trust the code or you don't. If > you don't trust the code, then even compiling it yourself adds no > additional protection. Trying to avoid binaries from "weird" sources probably just adds a sense of false security. Sometimes false security is the best you can get. Have fun and stay safe, Jarmo
Re: 9.5: coping with loss of ditaa.jar
Howdy. "Thomas S. Dye" writes: >> 2. Use the program "ditaa" (not ditaa.jar) that comes with your >>operating system. This _may_ work, but I have not been ableto >> misuse >>the settings in ob-ditaa widely enough yet to create aworking >>solution. > > This worked for me on Ubuntu 20.04, if it is helpful. > > sudo apt-get install ditaa > > Then set org-ditaa-jar-path to "/usr/bin/ditaa". I get an error: Error: Invalid or corrupt jarfile /usr/bin/ditaa What I also tried to do is to change org-babel-ditaa-java-cmd to "ditaa" and modify other parameters such as org-ditaa-jar-option accordingly. But no cigar so far. Have fun and stay safe, Jarmo
Re: 9.5: coping with loss of ditaa.jar
Colin Baxter writes: >> Jarmo Hurri writes: > > >> 3. Copy ditaa.jar from previous version of org. Works in the short >> run, but I do not think we want to advocate this: "We took ditaa.jar >> out of org, so you will want to download an earlier version of org to >> make ditaa work." > > Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a > previous org-mode ditaa.jar and have no issues. Sorry for my confusing language: I meant "you need to download an earlier version of org _and take ditaa.jar from it_ to make ditaa work." So I agree: no issues with this approach, but I do not think this is what we would like users to have to do. Have fun and stay safe, Jarmo
Re: 9.5: coping with loss of ditaa.jar
Aloha, Jarmo Hurri writes: Greetings. 2. Use the program "ditaa" (not ditaa.jar) that comes with your operating system. This _may_ work, but I have not been able to misuse the settings in ob-ditaa widely enough yet to create a working solution. This worked for me on Ubuntu 20.04, if it is helpful. sudo apt-get install ditaa Then set org-ditaa-jar-path to "/usr/bin/ditaa". All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: 9.5: coping with loss of ditaa.jar
Another alternative which I just found is the ditaa version on github, which has SVG support. See https://github.com/stathissideris/ditaa. If you click on the 'release' link on the right, there is the most recent release, which includes a link to a standalone ditaa.jar file. I've not tried this version, but suspect it will work fine (assuming they use semantic versioning, which indicates the API has not changed).
Re: 9.5: coping with loss of ditaa.jar
Jarmo Hurri writes: > Greetings. > > Let me collect the suggested responses with their merits and potential > issues. > > 1. Use ditaa.jar that comes with your operating system. Perfect if this >works. Seems to work e.g. in Debian, does not seem to work with >Fedora. Perhaps because one is a standalone library and the other one >is not. Could also be a version number issue. > > 2. Use the program "ditaa" (not ditaa.jar) that comes with your >operating system. This _may_ work, but I have not been able to misuse >the settings in ob-ditaa widely enough yet to create a working >solution. > > 3. Copy ditaa.jar from previous version of org. Works in the short run, >but I do not think we want to advocate this: "We took ditaa.jar out >of org, so you will want to download an earlier version of org to >make ditaa work." > > 4. Use precompiled binary ditaa.jar from some site. Will probably work, >but me and some other paranoids try to avoid using binaries from >sources which we do not consider reliable. > > 5. Compile ditaa.jar yourself. At least for me, does not work at the >moment. > I think you missed one obvious solution - donwload the jar file from the ditaa project homepage on sourceforge. This is what I did some years ago (there has not been an update to ditaa since 2013) and I placed the jar file in a lib folder on my system (completely separate from org, emacs etc) and then just set the path in my init file. This has been in place for me for at least 5 years (since I setup this computer) and has not needed to be changed through many updates/upgrades of both org and emacs. I don't think you need to be paranoid about downloading the jar file from the project homepage - either you trust the code or you don't. If you don't trust the code, then even compiling it yourself adds no additonal protection.
Re: 9.5: coping with loss of ditaa.jar
> Jarmo Hurri writes: > 3. Copy ditaa.jar from previous version of org. Works in the short > run, but I do not think we want to advocate this: "We took > ditaa.jar out of org, so you will want to download an earlier > version of org to make ditaa work." Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a previous org-mode ditaa.jar and have no issues.
Re: 9.5: coping with loss of ditaa.jar
Greetings. Let me collect the suggested responses with their merits and potential issues. 1. Use ditaa.jar that comes with your operating system. Perfect if this works. Seems to work e.g. in Debian, does not seem to work with Fedora. Perhaps because one is a standalone library and the other one is not. Could also be a version number issue. 2. Use the program "ditaa" (not ditaa.jar) that comes with your operating system. This _may_ work, but I have not been able to misuse the settings in ob-ditaa widely enough yet to create a working solution. 3. Copy ditaa.jar from previous version of org. Works in the short run, but I do not think we want to advocate this: "We took ditaa.jar out of org, so you will want to download an earlier version of org to make ditaa work." 4. Use precompiled binary ditaa.jar from some site. Will probably work, but me and some other paranoids try to avoid using binaries from sources which we do not consider reliable. 5. Compile ditaa.jar yourself. At least for me, does not work at the moment. To summarize: on Fedora, no working long-term solution so far. Have fun and stay safe, Jarmo
Re: 9.5: coping with loss of ditaa.jar
On Tuesday, 5 Oct 2021 at 00:28, Tim Cross wrote: > I suspect the difference is between having what Java calls a > 'stand-alone' jar and a library jar. [...] > Most people will want the stand-alone version. That sounds like a reasonable summary. It will be good to get confirmation along the way and a clear directive on how to ensure org knows how to use the jar file. I do rely on ditaa (mostly for teaching related activities) and hadn't thought about the implications of having the ditaa.jar file moved out of org-contrib. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: 9.5: coping with loss of ditaa.jar
Eric S Fraga writes: > On Sunday, 3 Oct 2021 at 07:25, Jarmo Hurri wrote: >> 1. I am running Fedora 34, where ditaa is available as a >>package. However, just pointing org-ditaa-jar-path to the correct >>location /usr/share/java/ditaa.jar is not sufficient, because doing >>so leads to errors when trying to execute a ditaa babel block: > > On Debian 11 (bullseye, most recent stable version), this works just > fine for me. I didn't need to feed any parameters, as you have > suggested being necessary. I don't know why, mind you. It could be a > different version of ditaa.jar? On Debian 11, the version installed is > 0.10+ds1-1.2. I suspect the difference is between having what Java calls a 'stand-alone' jar and a library jar. With a 'stand-alone' jar, all dependencies needed by the java program are bundled into the jar. With a library jar, only the specific code that makes up the library is included. It is a little like static versus dynamic linking of libraries. The idea is that with the lib only jar, you would already have the library dependencies installed (via maven or similar). >From the OP's original post, my guess is the jar they had was only the library, not a stand-alone jar with all the dependencies included. The ditta release page holds both stand-alone and minimal lib jars from memory. Most people will want the stand-alone version.
Re: 9.5: coping with loss of ditaa.jar
I should have added, to my previous response, that, at least on my system, the jar file is installed in /usr/share/ditaa/ditaa.jar, not /usr/share/java/ditaa.jar. I don't know if this is relevant at all. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: 9.5: coping with loss of ditaa.jar
On Sunday, 3 Oct 2021 at 07:25, Jarmo Hurri wrote: > 1. I am running Fedora 34, where ditaa is available as a >package. However, just pointing org-ditaa-jar-path to the correct >location /usr/share/java/ditaa.jar is not sufficient, because doing >so leads to errors when trying to execute a ditaa babel block: On Debian 11 (bullseye, most recent stable version), this works just fine for me. I didn't need to feed any parameters, as you have suggested being necessary. I don't know why, mind you. It could be a different version of ditaa.jar? On Debian 11, the version installed is 0.10+ds1-1.2. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: 9.5: coping with loss of ditaa.jar
> Arne Babenhauserheide writes: > Max Nikulin writes: >> On 03/10/2021 11:25, Jarmo Hurri wrote: >>> I use ditaa with org on a regular basis. Now that ditaa.jar is >>> out of org 9.5, I need to cope with the situtation. I see two >>> options, and neither was successful today. This is sort of what >>> I was afraid of when I voted for keeping ditaa bundled with org. >>> 1. I am running Fedora 34, where ditaa is available as a >>> package. However, just pointing org-ditaa-jar-path to the >>> correct location /usr/share/java/ditaa.jar is not sufficient, >>> because doing so leads to errors when trying to execute a ditaa >>> babel block: >> >> I am not a ditaa user currently, but generally it should be the >> preferred option. I have not looked into ob-ditaa.el however to >> realize if it has enough defcustom options. > A short-term quickfix could be to copy the jar from an older > orgmode and point to that. Indeed. That works for me. Best wishes, Colin Baxter signature.asc Description: PGP signature
Re: 9.5: coping with loss of ditaa.jar
Max Nikulin writes: > On 03/10/2021 11:25, Jarmo Hurri wrote: >> I use ditaa with org on a regular basis. Now that ditaa.jar is out >> of >> org 9.5, I need to cope with the situtation. >> I see two options, and neither was successful today. This is sort of >> what I was afraid of when I voted for keeping ditaa bundled with org. >> 1. I am running Fedora 34, where ditaa is available as a >> package. However, just pointing org-ditaa-jar-path to the correct >> location /usr/share/java/ditaa.jar is not sufficient, because doing >> so leads to errors when trying to execute a ditaa babel block: > > I am not a ditaa user currently, but generally it should be the > preferred option. I have not looked into ob-ditaa.el however to > realize if it has enough defcustom options. A short-term quickfix could be to copy the jar from an older orgmode and point to that. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: 9.5: coping with loss of ditaa.jar
On 03/10/2021 11:25, Jarmo Hurri wrote: I use ditaa with org on a regular basis. Now that ditaa.jar is out of org 9.5, I need to cope with the situtation. I see two options, and neither was successful today. This is sort of what I was afraid of when I voted for keeping ditaa bundled with org. 1. I am running Fedora 34, where ditaa is available as a package. However, just pointing org-ditaa-jar-path to the correct location /usr/share/java/ditaa.jar is not sufficient, because doing so leads to errors when trying to execute a ditaa babel block: I am not a ditaa user currently, but generally it should be the preferred option. I have not looked into ob-ditaa.el however to realize if it has enough defcustom options. 2. Ditaa is available via github at https://github.com/stathissideris/ditaa The developer section points to building with some clojure build system lein, which is not available in my system, and in Fedora, running dnf list available '*lein*' Option 3: jar built by ditaa developers https://github.com/stathissideris/ditaa/releases