The fate of ditaa.jar (9.4.5.)

The fate of ditaa.jar (9.4.5.)

[Jarmo Hurri]

Greetings.

I pulled the latest master and noticed that contrib has been moved into
a separate repository. I also cloned this contrib repository, but can
not find the file

scripts/ditaa.jar

in the repo. In fact, there is no directory scripts in the repo.

The documentation in the latest master states that

Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
packaged into the org-contrib repository.

How should I proceed? Should I build this separately

https://github.com/stathissideris/ditaa

or will it still be included into contrib?

Have fun and stay safe!

Jarmo

Re: The fate of ditaa.jar (9.4.5.)

[Eric S Fraga]

On Monday, 10 May 2021 at 14:28, Jarmo Hurri wrote:
> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar
>
> in the repo. In fact, there is no directory scripts in the repo.

Bastien mentioned to me, off list, that he was going to move ditaa.jar
to Worg, specifically to worg/code/scripts, but this does not seem to
have taken place (yet).

FYI, Debian has the ditaa package which includes ditaa.jar.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: The fate of ditaa.jar (9.4.5.)

[Russell Adams]

On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar
>
> in the repo. In fact, there is no directory scripts in the repo.

I actually never considered this might be packaged with Org. I always
thought I had to install it separately, like my Latex distribution or
PlantUML.



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>> I pulled the latest master and noticed that contrib has been moved into
>> a separate repository. I also cloned this contrib repository, but can
>> not find the file
>>
>> scripts/ditaa.jar
>>
>> in the repo. In fact, there is no directory scripts in the repo.
>
> I actually never considered this might be packaged with Org. I always
> thought I had to install it separately, like my Latex distribution or
> PlantUML.

Bundling this makes ditaa code blocks just work. Otherwise they won’t
work on every org-install.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

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

> Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
>
>> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>>> I pulled the latest master and noticed that contrib has been moved into
>>> a separate repository. I also cloned this contrib repository, but can
>>> not find the file
>>>
>>> scripts/ditaa.jar
>>>
>>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> I actually never considered this might be packaged with Org. I always
>> thought I had to install it separately, like my Latex distribution or
>> PlantUML.
>
> Bundling this makes ditaa code blocks just work. Otherwise they won’t
> work on every org-install.

The user still needs a Java runtime installed on his/her compute, so
bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
work on every org-install.

Instead a less informaed user, not used to run java programs, might be
left with a not working application that fails silently or to the user
incomprehensible error message.

Better to point user to ditaa's sources/releases and inform it is
optional with org. That way non-informed user will have to install java
and ditaa and will at least have an idea where to look when things go wrong.

Re: The fate of ditaa.jar (9.4.5.)

[Christopher Dimech]

If org-mode wants to support ditaa, it is a requirement to inform the user how to
get the software and install it.  Moving into into a separate repository without
appropriately telling the user introduces the problem that users will miss out
on free software that they would otherwise have used.  Using org should not be made 
more difficult than it already is. 
  

> Sent: Tuesday, May 11, 2021 at 8:49 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> 
> > Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
> >
> >> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
> >>> I pulled the latest master and noticed that contrib has been moved into
> >>> a separate repository. I also cloned this contrib repository, but can
> >>> not find the file
> >>>
> >>> scripts/ditaa.jar
> >>>
> >>> in the repo. In fact, there is no directory scripts in the repo.
> >>
> >> I actually never considered this might be packaged with Org. I always
> >> thought I had to install it separately, like my Latex distribution or
> >> PlantUML.
> >
> > Bundling this makes ditaa code blocks just work. Otherwise they won’t
> > work on every org-install.
> 
> The user still needs a Java runtime installed on his/her compute, so
> bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
> work on every org-install.
> 
> Instead a less informaed user, not used to run java programs, might be
> left with a not working application that fails silently or to the user
> incomprehensible error message.
> 
> Better to point user to ditaa's sources/releases and inform it is
> optional with org. That way non-informed user will have to install java
> and ditaa and will at least have an idea where to look when things go wrong.
> 
>

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

> If org-mode wants to support ditaa, it is a requirement to inform the user how to
> get the software and install it.  Moving into into a separate repository without
> appropriately telling the user introduces the problem that users will miss out
> on free software that they would otherwise have used.  Using org should not be made 
> more difficult than it already is. 
>   
Another problem I didn't mention in previous replay, is that user can
have wrong (outdated) version of Java installed on his/her machine which
might not be compatible with ditaa version org mode ships, which may
introduce further questions and problems. IMO I think it is better to
leave out 3rd party applications and let users install those on their
own. 

>> Sent: Tuesday, May 11, 2021 at 8:49 AM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: emacs-orgmode@gnu.org
>> Subject: Re: The fate of ditaa.jar (9.4.5.)
>>
>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>> 
>> > Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
>> >
>> >> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>> >>> I pulled the latest master and noticed that contrib has been moved into
>> >>> a separate repository. I also cloned this contrib repository, but can
>> >>> not find the file
>> >>>
>> >>> scripts/ditaa.jar
>> >>>
>> >>> in the repo. In fact, there is no directory scripts in the repo.
>> >>
>> >> I actually never considered this might be packaged with Org. I always
>> >> thought I had to install it separately, like my Latex distribution or
>> >> PlantUML.
>> >
>> > Bundling this makes ditaa code blocks just work. Otherwise they won’t
>> > work on every org-install.
>> 
>> The user still needs a Java runtime installed on his/her compute, so
>> bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
>> work on every org-install.
>> 
>> Instead a less informaed user, not used to run java programs, might be
>> left with a not working application that fails silently or to the user
>> incomprehensible error message.
>> 
>> Better to point user to ditaa's sources/releases and inform it is
>> optional with org. That way non-informed user will have to install java
>> and ditaa and will at least have an idea where to look when things go wrong.
>> 
>>

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Arthur Miller <arthur.miller@live.com> writes:

> Christopher Dimech <dimech@gmx.com> writes:
>
>> If org-mode wants to support ditaa, it is a requirement to inform the user how to
>> get the software and install it.  Moving into into a separate repository without
>> appropriately telling the user introduces the problem that users will miss out
>> on free software that they would otherwise have used.  Using org should not be made 
>> more difficult than it already is. 
>>   
> Another problem I didn't mention in previous replay, is that user can
> have wrong (outdated) version of Java installed on his/her machine which
> might not be compatible with ditaa version org mode ships, which may
> introduce further questions and problems. IMO I think it is better to
> leave out 3rd party applications and let users install those on their
> own. 

The old version should just keep working. It requires a Java older than
Java 8, and Java 8 is available everywhere.

For the new releases that is less clear, since ditaa is adding Clojure.

I would bundle the old version to keep old documents working (I do not
want org-mode to be volatile software[1] that breaks existing documents
with an update), but notify the user that a new version exists.

[1]: https://stevelosh.com/blog/2012/04/volatile-software/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

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

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>>> If org-mode wants to support ditaa, it is a requirement to inform the user how to
>>> get the software and install it.  Moving into into a separate repository without
>>> appropriately telling the user introduces the problem that users will miss out
>>> on free software that they would otherwise have used.  Using org should not be made 
>>> more difficult than it already is. 
>>>   
>> Another problem I didn't mention in previous replay, is that user can
>> have wrong (outdated) version of Java installed on his/her machine which
>> might not be compatible with ditaa version org mode ships, which may
>> introduce further questions and problems. IMO I think it is better to
>> leave out 3rd party applications and let users install those on their
>> own. 
>
> The old version should just keep working. It requires a Java older than
> Java 8, and Java 8 is available everywhere.
I don't think that would be the case. Java is considered unsafe software
so I wouldn't rely on older versions being pre-installed and avialable everywhere.

> I would bundle the old version to keep old documents working (I do not
> want org-mode to be volatile software[1] that breaks existing documents
> with an update), but notify the user that a new version exists.

Since you already have Java and ditaa installed on your computer, your
older documents won't get broken. 

By the way, how difficult is to download one file from the internet
(ditaa.jar) if you are an user?

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Arthur Miller <arthur.miller@live.com> writes:

> I don't think that would be the case. Java is considered unsafe software
> so I wouldn't rely on older versions being pre-installed and avialable everywhere.

Java is not considered unsafe software — not any more than any
interpreted language. What’s unsafe are Java applets, but those are not
what ditaa uses.

>> I would bundle the old version to keep old documents working (I do not
>> want org-mode to be volatile software[1] that breaks existing documents
>> with an update), but notify the user that a new version exists.
>
> Since you already have Java and ditaa installed on your computer, your
> older documents won't get broken. 

I have Java, but not ditaa, because Java is packaged in my distribution
and ditaa is not. My build pipelines use ditaa as shipped with org-mode.

Different from plantuml, there is no ditaa-runner to install as
application.

So unbundling ditaa breaks my documents when updating org-mode. The same
for everyone else who used a standard ditaa-setup with org-mode.

> By the way, how difficult is to download one file from the internet
> (ditaa.jar) if you are an user?

That’s not the point. The point is that every single user with a ditaa
block has to do it.

Ask the other way round: What is the benefit of removing ditaa from org?
If you want to force most current org-ditaa users to unbreak their setup
after update, there should be a significant tangible benefit.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: The fate of ditaa.jar (9.4.5.)

[Russell Adams]

On Wed, May 12, 2021 at 11:41:48AM +0200, Dr. Arne Babenhauserheide wrote:
> I have Java, but not ditaa, because Java is packaged in my distribution
> and ditaa is not. My build pipelines use ditaa as shipped with
> org-mode.

My opinion is that Org has integration for many external tools, but
doesn't ship them. I don't think Org should be shipping anything that
isn't Org's own code due to maintainer overhead, potential
legal/license issues, and inconsistency across tools. We don't ship
Latex distributions or gnuplot either.

> So unbundling ditaa breaks my documents when updating org-mode. The same
> for everyone else who used a standard ditaa-setup with org-mode.

I think it's a reasonable request to make of an end user that if you
want to use Org's integration with the tool, you ensure the tool is
installed first. If your Linux distribution doesn't provide a package
for ditaa, file a bug report or a feature request with
them. Alternatively you can install it yourself as it's just one .jar
file.

Perhaps Org should show a better error message if ditaa isn't found.

> Ask the other way round: What is the benefit of removing ditaa from org?
> If you want to force most current org-ditaa users to unbreak their setup
> after update, there should be a significant tangible benefit.

Org's codebase is always undergoing change and right now there's a
significant cleanup effort going on to separate contrib out of core. I
expect removing ditaa was part of that. I defer here to the wisdom of
the maintainers that there is benefit to reorganizing the code base,
even if it's just to simplify their job as maintainers.

I respect that it's causing you some personal inconvenience, however
it's not a major breakage. It should be simple to resolve by
installing locally.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: The fate of ditaa.jar (9.4.5.)

[Jarmo Hurri]

Greetings.

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

> Arthur Miller <arthur.miller@live.com> writes:
>
>> By the way, how difficult is to download one file from the internet
>> (ditaa.jar) if you are an user?
>
> That’s not the point. The point is that every single user with a ditaa
> block has to do it.
>
> Ask the other way round: What is the benefit of removing ditaa from
> org?  If you want to force most current org-ditaa users to unbreak
> their setup after update, there should be a significant tangible
> benefit.

I agree.

One thing I like about org is that most things work out of the box.
While I can download/install/compile/whatever ditaa.jar, having to do so
adds a step. This extra step will result in fewer people using the
combination of org and ditaa. I do not think that is a good direction.

Comparing ditaa to latex/java/C/such does not feel fair, since distros
support standard software, and ditaa does not seem to qualify. But this
is an assumption. At least my distro does not support ditaa in a
package.

Just my opinion. As always, happy to leave the final decision to the
wise ones.

Have fun and stay safe!

Jarmo

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Jarmo Hurri <jarmo.hurri@iki.fi> writes:

> Greetings.
>
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> By the way, how difficult is to download one file from the internet
>>> (ditaa.jar) if you are an user?
>>
>> That’s not the point. The point is that every single user with a ditaa
>> block has to do it.
>>
>> Ask the other way round: What is the benefit of removing ditaa from
>> org?  If you want to force most current org-ditaa users to unbreak
>> their setup after update, there should be a significant tangible
>> benefit.
>
> I agree.
>
> One thing I like about org is that most things work out of the box.

If bundled ditaa is not compatible with jre installed on users
computer, or there is no jre installed, and user is not a programmer or
used to Java, how many steps it adds to such a user to sort out why org
does not work for him/her "out of the box"? Just to save some experienced
user an extra step, that probably does not even affect them since they
already have java and ditaa on their computers.

> Comparing ditaa to latex/java/C/such does not feel fair, since distros
Ditaa requires jre to work. Should org distribute a version of jre too
to make it sure it works on user computer "out of the box"?

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Arthur Miller <arthur.miller@live.com> writes:

> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
>> Greetings.
>>
>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> By the way, how difficult is to download one file from the internet
>>>> (ditaa.jar) if you are an user?
>>>
>>> That’s not the point. The point is that every single user with a ditaa
>>> block has to do it.
>>>
>>> Ask the other way round: What is the benefit of removing ditaa from
>>> org?  If you want to force most current org-ditaa users to unbreak
>>> their setup after update, there should be a significant tangible
>>> benefit.
>>
>> I agree.
>>
>> One thing I like about org is that most things work out of the box.
>
> If bundled ditaa is not compatible with jre installed on users
> computer, or there is no jre installed, and user is not a programmer or
> used to Java, how many steps it adds to such a user to sort out why org
> does not work for him/her "out of the box"? Just to save some experienced
> user an extra step, that probably does not even affect them since they
> already have java and ditaa on their computers.

The difference is not about the difference between experienced or
beginner. The difference is that „use your package manager to get Java“
or „get openjdk“ is an operation that only uses standard installation
processes.

„Get this jar-file from somewhere and drop it somewhere and then change
this configuration to point to it“ is not a standard installation
action.

If Java is missing, org can simply report „no java found, please install
openjdk from <linux: your package manager | windows/macos:
https://adoptopenjdk.net/installation.html>“ and the user can install it
like any other software.

This is not the case with ditaa. Ditaa is no standard application with
installer/setup/…, but a jar-file.

And removing it breaks existing setups when org-mode is updated.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

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

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>>
>>> Greetings.
>>>
>>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>>>
>>>> Arthur Miller <arthur.miller@live.com> writes:
>>>>
>>>>> By the way, how difficult is to download one file from the internet
>>>>> (ditaa.jar) if you are an user?
>>>>
>>>> That’s not the point. The point is that every single user with a ditaa
>>>> block has to do it.
>>>>
>>>> Ask the other way round: What is the benefit of removing ditaa from
>>>> org?  If you want to force most current org-ditaa users to unbreak
>>>> their setup after update, there should be a significant tangible
>>>> benefit.
>>>
>>> I agree.
>>>
>>> One thing I like about org is that most things work out of the box.
>>
>> If bundled ditaa is not compatible with jre installed on users
>> computer, or there is no jre installed, and user is not a programmer or
>> used to Java, how many steps it adds to such a user to sort out why org
>> does not work for him/her "out of the box"? Just to save some experienced
>> user an extra step, that probably does not even affect them since they
>> already have java and ditaa on their computers.
>
> The difference is not about the difference between experienced or
> beginner. The difference is that „use your package manager to get Java“
> or „get openjdk“ is an operation that only uses standard installation
> processes.
>
> „Get this jar-file from somewhere and drop it somewhere and then change
> this configuration to point to it“ is not a standard installation
> action.
>
> If Java is missing, org can simply report „no java found, please install
> openjdk from <linux: your package manager | windows/macos:
> https://adoptopenjdk.net/installation.html>“ and the user can install it
> like any other software.
So can org also say: "ditaa is missing, please install from the link
... " :-)

> This is not the case with ditaa. Ditaa is no standard application with
> installer/setup/…, but a jar-file.

Exactly, so it is enough to just download a single file and point your
org to it with one `setq' in your init file. So it does not need a
pacakge managmenet on os level.

However, Org could also simply say: use another distro that has ditaa in
it's repository, such as Arch Linuz (in AUR).

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Arthur Miller <arthur.miller@live.com> writes:

> Exactly, so it is enough to just download a single file and point your
> org to it with one `setq' in your init file. So it does not need a
> pacakge managmenet on os level.

Package management is how users should install software. Otherwise you
quickly reach the point where they blindly curl and run untrusted
shell-scripts from shady websites.

> However, Org could also simply say: use another distro that has ditaa in
> it's repository, such as Arch Linuz (in AUR).

That would be openly hostile.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: The fate of ditaa.jar (9.4.5.)

[Christopher Dimech]

> Sent: Friday, May 14, 2021 at 5:30 PM
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> To: "Arthur Miller" <arthur.miller@live.com>
> Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> 
> Arthur Miller <arthur.miller@live.com> writes:
> 
> > Exactly, so it is enough to just download a single file and point your
> > org to it with one `setq' in your init file. So it does not need a
> > pacakge managmenet on os level.
> 
> Package management is how users should install software. Otherwise you
> quickly reach the point where they blindly curl and run untrusted
> shell-scripts from shady websites.

I agree with the assessment regarding shady websites.
 
> > However, Org could also simply say: use another distro that has ditaa in
> > it's repository, such as Arch Linuz (in AUR).
> 
> That would be openly hostile.

If there exists the serious problem of not finding ditaa, then ditaa should be provided.
For the rest there exist no problem and users can easily install from their Package Manager.

You can't brush off a boyfriend and expect him to do you a favor using Free Software
by telling him to use another distro.  ;)
 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, May 14, 2021 at 5:30 PM
>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> To: "Arthur Miller" <arthur.miller@live.com>
>> Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
>> Subject: Re: The fate of ditaa.jar (9.4.5.)
>>
>> 
>> Arthur Miller <arthur.miller@live.com> writes:
>> 
>> > Exactly, so it is enough to just download a single file and point your
>> > org to it with one `setq' in your init file. So it does not need a
>> > pacakge managmenet on os level.
>> 
>> Package management is how users should install software. Otherwise you
>> quickly reach the point where they blindly curl and run untrusted
>> shell-scripts from shady websites.
>
> I agree with the assessment regarding shady websites.
>  
>> > However, Org could also simply say: use another distro that has ditaa in
>> > it's repository, such as Arch Linuz (in AUR).
>> 
>> That would be openly hostile.

No is not. There are so many distributions that are half-done,
unmaintained, etc. By the way, if your distro does not have a package
for ditaa, then you might maybe consider doing a community service and
provide a package script for your distro? I guess your distro have some
way for users to contribute a package?

> If there exists the serious problem of not finding ditaa, then ditaa should be provided.
> For the rest there exist no problem and users can easily install from their Package Manager.
>
> You can't brush off a boyfriend and expect him to do you a favor using Free Software
> by telling him to use another distro.  ;)
>  

:-) It is just the usual one: "you deserve a better one ...."

Re: The fate of ditaa.jar (9.4.5.)

[Christopher Dimech]

> Sent: Friday, May 14, 2021 at 11:23 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, May 14, 2021 at 5:30 PM
> >> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> >> To: "Arthur Miller" <arthur.miller@live.com>
> >> Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
> >> Subject: Re: The fate of ditaa.jar (9.4.5.)
> >>
> >>
> >> Arthur Miller <arthur.miller@live.com> writes:
> >>
> >> > Exactly, so it is enough to just download a single file and point your
> >> > org to it with one `setq' in your init file. So it does not need a
> >> > pacakge managmenet on os level.
> >>
> >> Package management is how users should install software. Otherwise you
> >> quickly reach the point where they blindly curl and run untrusted
> >> shell-scripts from shady websites.
> >
> > I agree with the assessment regarding shady websites.
> >
> >> > However, Org could also simply say: use another distro that has ditaa in
> >> > it's repository, such as Arch Linuz (in AUR).
> >>
> >> That would be openly hostile.
>
> No is not. There are so many distributions that are half-done,
> unmaintained, etc. By the way, if your distro does not have a package
> for ditaa, then you might maybe consider doing a community service and
> provide a package script for your distro? I guess your distro have some
> way for users to contribute a package?
>
> > If there exists the serious problem of not finding ditaa, then ditaa should be provided.
> > For the rest there exist no problem and users can easily install from their Package Manager.
> >
> > You can't brush off a boyfriend and expect him to do you a favor using Free Software
> > by telling him to use another distro.  ;)
> >
>
> :-) It is just the usual one: "you deserve a better one ...."

That would be true if you got a crappy one. :)

Re: The fate of ditaa.jar (9.4.5.)

[Nick Dokos]

Jarmo Hurri <jarmo.hurri@iki.fi> writes:

> Greetings.
>
> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar
>
> in the repo. In fact, there is no directory scripts in the repo.
>
> The documentation in the latest master states that
>
> Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
> packaged into the org-contrib repository.
>
> How should I proceed? Should I build this separately
>
> https://github.com/stathissideris/ditaa

You don't need to build it: it's available in the release area

https://github.com/stathissideris/ditaa/releases

>
> or will it still be included into contrib?

In general, I think it's a better idea to point to the canonical sources
and document how to integrate it into Org mode, than bundle things like
that, but I have no idea how things are going to go. I'm sure there will
be some problems that will need fixing one way or another.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: The fate of ditaa.jar (9.4.5.)

[Christopher Dimech]

If having the source is not as easy as getting a link that is dependable,
then it got to be bundled.  I rather use a version that works than nothing
at all.  I have used ditaa in org for the documentation of texinfo.

> Sent: Tuesday, May 11, 2021 at 6:41 AM
> From: "Nick Dokos" <ndokos@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
> 
> > Greetings.
> >
> > I pulled the latest master and noticed that contrib has been moved into
> > a separate repository. I also cloned this contrib repository, but can
> > not find the file
> >
> > scripts/ditaa.jar
> >
> > in the repo. In fact, there is no directory scripts in the repo.
> >
> > The documentation in the latest master states that
> >
> > Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
> > packaged into the org-contrib repository.
> >
> > How should I proceed? Should I build this separately
> >
> > https://github.com/stathissideris/ditaa
> 
> You don't need to build it: it's available in the release area
> 
> https://github.com/stathissideris/ditaa/releases
> 
> >
> > or will it still be included into contrib?
> 
> In general, I think it's a better idea to point to the canonical sources
> and document how to integrate it into Org mode, than bundle things like
> that, but I have no idea how things are going to go. I'm sure there will
> be some problems that will need fixing one way or another.
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
> 
> 
>

Re: The fate of ditaa.jar (9.4.5.)

[Tim Cross]

Nick Dokos <ndokos@gmail.com> writes:

> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
>> Greetings.
>>
>> I pulled the latest master and noticed that contrib has been moved into
>> a separate repository. I also cloned this contrib repository, but can
>> not find the file
>>
>> scripts/ditaa.jar
>>
>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> The documentation in the latest master states that
>>
>> Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
>> packaged into the org-contrib repository.
>>
>> How should I proceed? Should I build this separately
>>
>> https://github.com/stathissideris/ditaa
>
> You don't need to build it: it's available in the release area
>
> https://github.com/stathissideris/ditaa/releases
>
>>
>> or will it still be included into contrib?
>
> In general, I think it's a better idea to point to the canonical sources
> and document how to integrate it into Org mode, than bundle things like
> that, but I have no idea how things are going to go. I'm sure there will
> be some problems that will need fixing one way or another.

I agree. As pointed out already, just bundling the jar file is not
sufficient as you need a java runtime as well. If we bundle it, we also
need to ensure it is updated if/when new jar versions are released. 

Better to clearly document where to get the dependencies and point to
the appropriate installation instructions.

I think we also need to keep in mind that we are currently in a bit of a
transition stage with the move to using ELPA and non-gnu ELPA. There
will be teething problems needing to be worked through both before and
after the transition. 
-- 
Tim Cross

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

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


Tim Cross <theophilusx@gmail.com> writes:
> I agree. As pointed out already, just bundling the jar file is not
> sufficient as you need a java runtime as well.

Java is available in my distribution, ditaa is not. Removing ditaa from
org means that I have to do manual installation and configuration, while
with ditaa bundled, org-mode can simply note that I need java installed.

> If we bundle it, we also need to ensure it is updated if/when new jar
> versions are released.

We can do that, but we don’t have to. As long as the bundled jar works,
it is much better than no jar. And users can use newer version as they
like by changing the jar-path.

Note that this isn’t about security, since even if an old version of
ditaa should turn out to be vulnerable, this would still be less
dangerous than a shell-block. Therefore old versions of ditaa are
completely fine.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

he fate of ditaa.jar (9.4.5.)

[Christopher Dimech]

> Sent: Tuesday, May 11, 2021 at 6:35 PM
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> 
> Tim Cross <theophilusx@gmail.com> writes:
> > I agree. As pointed out already, just bundling the jar file is not
> > sufficient as you need a java runtime as well.
> 
> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
> 
> > If we bundle it, we also need to ensure it is updated if/when new jar
> > versions are released.
> 
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar. And users can use newer version as they
> like by changing the jar-path.

A jar that works would be good as initial setup, then people can change that
as they wish.

> Note that this isn’t about security, since even if an old version of
> ditaa should turn out to be vulnerable, this would still be less
> dangerous than a shell-block. Therefore old versions of ditaa are
> completely fine.
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: The fate of ditaa.jar (9.4.5.)

[Tim Cross]

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

> [[PGP Signed Part:Undecided]]
>
> Tim Cross <theophilusx@gmail.com> writes:
>> I agree. As pointed out already, just bundling the jar file is not
>> sufficient as you need a java runtime as well.
>
> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
>

I get that. However, this is of course not the case for many users (Mac,
Windows). Having to install additional software to realise org
functionality is normal for much of org-mode. In fact, I had to install
ditta when I first used it because it wasn't bundled. That was not an
issue and no surprise given I also had to install textlive, plantuml,
graphviz, taskjuggler, ledger, sqlite and many other things.

I understand the convenience for users argument. However, I think we
also need to consider the maintenance overheads and consistency aspects
as well (including dealing with bug reports when it doesn't work). 

>> If we bundle it, we also need to ensure it is updated if/when new jar
>> versions are released.
>
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar. And users can use newer version as they
> like by changing the jar-path.
>
> Note that this isn’t about security, since even if an old version of
> ditaa should turn out to be vulnerable, this would still be less
> dangerous than a shell-block. Therefore old versions of ditaa are
> completely fine.
>

My thoughts were more about bugs and confusing deprecation warnings
which can arise when using an older jar file with a more recent jre.

Ultimately, it will fall to whoever steps up to maintain ditta support
to decide. 

-- 
Tim Cross

Re: The fate of ditaa.jar (9.4.5.)

[TEC]

Tim Cross <theophilusx@gmail.com> writes:

> I also had to install textlive, plantuml, graphviz, taskjuggler,
> ledger, sqlite and many other things.

Perhaps it would be good to make a table of

| software | needed for | package name | download page |

and/or prompt users when an action requiring another executable is
undertaken if it isn't found.

--
Timothy

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

TEC <tecosaur@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
>
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |

Maybe there could be a hash table where one can register a function with
a software, similar to how autoload works. but instead of specifying
file where function is found, we could specify a sotware/package name
and a link to download/main page?

Maybe function level is too granular, maybe per feature level?

> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.
>
I think it's a good idea.

A minor mode that can be turned off for experienced users but on by
default and maybe with knowledge where to find the required software,
i.e. a link that Emacs can open in default a web browser for the
user. Ultimate would be to offer a download, but considering all the
distros and possible dead links, probably better to go just for download
or main page.

Re: The fate of ditaa.jar (9.4.5.)

[Tim Cross]

TEC <tecosaur@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
>
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |
>
> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.

Useful additional documentation, assuming it can be maintained, is
rarely a bad idea. A table on worg (with maybe a link in the manual)
which lists all the org (and contrib) features, external dependencies
and link to canonical source would probably be a good idea.

I find it hard to remember how I worked out all the dependencies as I
adopted org as it was so long ago and I was already a heavy user of
many of the tools/dependencies of org. This makes it challenging to
appreciate how hard it can be for someone knew to org. On the other
hand, if we make it overly easy/automatic, we run the risk of
disempowering the user and making them more dependent on assistance from
others. Finding the right balance between informative and concise is a
challenge. If we provide too much information, it can be overwhelming,
too little and it can be confusing. I find it harder to write good
documentation than good code!


-- 
Tim Cross

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

>                           I find it harder to write good
> documentation than good code!

Yes indeed, takes so much more time than to just write the code :).

Re: [External] : Re: The fate of ditaa.jar (9.4.5.)

[Daniel Ortmann]

And perhaps maintain the table in elpa?

On 5/11/21 7:52 AM, TEC wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |
>
> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.
>
> --
> Timothy
>

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

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

> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
>
>> If we bundle it, we also need to ensure it is updated if/when new jar
>> versions are released.
>
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar.
Depending on what users have on their machines it may not work on their
machine. The bundled jar might ask for a version of Java runtime that
users does not have. There is no guarantee that every distribution comes
with java bundled either. For you it maybe works, for someone else it
might generate 1001 question and confusion when things don't work.

Re: The fate of ditaa.jar (9.4.5.)

[Bastien]

Hi Jarmo,

Jarmo Hurri <jarmo.hurri@iki.fi> writes:

> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar

It still lives here: https://orgmode.org/worg/code/scripts/ (I forgot
to push the files on Worg at first, but this is fixed.)

I also mentioned this more clearly in etc/ORG-NEWS, I agree we should
provide users with the relevant information here.

Thanks,

-- 
 Bastien