9.5: coping with loss of ditaa.jar

9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings.

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:

   Error: Unable to initialize main class org.stathissideris.ascii2image.core.CommandLineConverter
   Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException

   Taking a look at what the system binary "ditaa" does, I found the
   following shell script:

   # -----------------------------------------------------------------
   #!/usr/bin/bash
   #

   source /usr/share/java-utils/java-functions

   MAIN_CLASS=org.stathissideris.ascii2image.core.CommandLineConverter
   BASE_JARS="ditaa commons-cli xml-commons-apis batik"

   set_classpath $BASE_JARS

   run "$@"
   # -----------------------------------------------------------------

   Has anyone successfully fed all these parameters to ob-ditaa?

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*'

   gives me nothing useful.

   There are, however, ant build files available in ditaa repo under
   build. Then again, running ant with any parameters I could think of
   leads to the error

   BUILD FAILED
   /home/jarmo/src/ditaa/build/build.xml:6: The following error occurred while executing this line:
   /home/jarmo/src/ditaa/build/release.xml:67: /home/jarmo/src/ditaa/lib does not exist.

   Has anyone succesfully compiled ditaa for use with org?

Have fun and stay safe.

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Max Nikulin]

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

Re: 9.5: coping with loss of ditaa.jar

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]


Max Nikulin <manikulin@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: 9.5: coping with loss of ditaa.jar

[Colin Baxter]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

>>>>> Arne Babenhauserheide <arne_bab@web.de> writes:

    > Max Nikulin <manikulin@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: 9.5: coping with loss of ditaa.jar

[Eric S Fraga]

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

[Eric S Fraga]

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

[Tim Cross]

Eric S Fraga <e.fraga@ucl.ac.uk> 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

[Eric S Fraga]

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

[Jarmo Hurri]

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

[Colin Baxter 😺]

>>>>> Jarmo Hurri <jarmo.hurri@iki.fi> 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

[Tim Cross]

Jarmo Hurri <jarmo.hurri@iki.fi> 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

[Tim Cross]

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

[Thomas S. Dye]

Aloha,

Jarmo Hurri <jarmo.hurri@iki.fi> 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

[Jarmo Hurri]

Colin Baxter 😺 <m43cap@yandex.com> writes:

>>>>>> Jarmo Hurri <jarmo.hurri@iki.fi> 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

[Jarmo Hurri]

Howdy.

"Thomas S. Dye" <tsd@tsdye.online> writes:

>> 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".

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

[Jarmo Hurri]

Greetings Tim.

Tim Cross <theophilusx@gmail.com> 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

[Nick Dokos]

Tim Cross <theophilusx@gmail.com> 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