Importing PlantUML external file macro syntax is only using path from calling directory

[dduportal]

Expected Behavior

• Given I am using the macro syntax for loading an external plantUML file (e.g. plantuml::PATH[])
  • This syntax is written here: http://asciidoctor.org/news/2014/02/18/plain-text-diagrams-in-asciidoctor/#including-external-diagrams
• When I generate my document with the default HTML backoffice from another directory than the one containing my imported diagrams,
• Then I would want my generation to happen correctly, since my path is following the "include::" rules

The documentation at http://asciidoctor.org/docs/asciidoctor-diagram/#diagram-block-macro says:

When the source file name is a relative path it is resolved with respect to the location of the document being processed.

Current Behavior

• If run from the directory containing the imported diagrams, it works.
• Note that the syntax using a block and the include:: directive is always working
• If I change directory, then I got an error like this one:

  asciidoctor-diagram: ERROR: Failed to generate image: No such file or directory @ rb_file_s_mtime - activity_diagram.txt

Here is a full example for reproduction:

bash-4.3# pwd
/documents
bash-4.3# cat activity_diagram.txt 
@startuml
(*) --> "Initialization"

if "Some Test" then
  -->[true] "Some Activity"
  --> "Another activity"
  -right-> (*)
else
  ->[false] "Something else"
  -->[Ending process] (*)
endif

@enduml
bash-4.3# cat diag.adoc 

= Diagram PlantUML

Hello

== Inline PlantUML

[plantuml,sample-diagram,svg]
----
class Sample {
}
----

== PlantUML from external file with block syntax

[plantuml,activity,svg,align="center"]
----
include::activity_diagram.txt[]
----

== PlantUML from external file *without* block syntax

plantuml::activity_diagram.txt[format=svg,align="center"]
bash-4.3# asciidoctor -r asciidoctor-diagram diag.adoc 
bash-4.3# ls -ltr
total 72
-rw-r--r--    1 root     root           368 Dec 23 09:04 sample-with-latex-math.adoc
-rw-r--r--    1 root     root           705 Dec 23 09:04 basic-example.adoc
-rw-r--r--    1 root     root           199 Dec 23 09:04 activity_diagram.txt
-rw-r--r--    1 root     root          2498 Dec 23 09:35 sample-with-diagram.adoc
-rw-r--r--    1 root     root           351 Dec 23 09:40 diag.adoc
-rw-r--r--    1 root     root          2191 Dec 23 09:41 sample-diagram.svg
-rw-r--r--    1 root     root         31745 Dec 23 09:41 diag.html
-rw-r--r--    1 root     root          5968 Dec 23 09:41 activity_diagram.svg
-rw-r--r--    1 root     root          5962 Dec 23 09:41 activity.svg
bash-4.3# cd /tmp/
bash-4.3# asciidoctor -r asciidoctor-diagram /documents/diag.adoc 
asciidoctor-diagram: ERROR: Failed to generate image: No such file or directory @ rb_file_s_mtime - activity_diagram.txt
asciidoctor: FAILED: /documents/diag.adoc: Failed to load AsciiDoc document - No such file or directory @ rb_sysopen - activity_diagram.txt
  Use --trace for backtrace

[dduportal]

Thanks for fixing this @pepijnve !

[jvmlet]

There is the same issue when using !includesub someIncluded.puml!SECTION from some root.puml file.
Both someIncluded.puml and root.puml reside in the same folder.

[uniqueck]

Is this bug solved. I also work with !include in plantuml and get errors if I include these files in asciidoc. I can provide an example repository to reproduce these error.

[pepijnve]

@uniqueck it was fixed to the best of my knowledge. If you have a different reproduction scenario I'm happy to take another look.

[uniqueck]

@pepijnve So i think the problem is still the same. The base directory for the includes in plantuml files isn't correct. The base directory is related to the asciidoc document from which the plantuml or include macro is started, but it has to be the directory in which the includes plantuml is located. I created an example based on maven. asciidoctor-plantuml-examples / branch issue/asciidoctor/diagram/173

If i can help, let me know.

[pepijnve]

@uniqueck the include resolution that's done by asciidoctor-diagram only goes one level deep. I'll have to replace that with recursive include logic instead. Might be a good idea anyway since that will enable sending the diagram code off to a remote server.

[uniqueck]

@pepijnve should we reopen this issue? to watch the state for this issue?

[pepijnve]

I would suggest we make a new issue for the extend include resolution behaviour.

This is going to be tricky to implement since it requires making a full implementation of PlantUML's preprocessor to do this correctly. If you throw subpart inclusion and conditionals into the mix this starts to look like a huge can of worms...

The alternative is that we pass the correct working directory to the PlantUML server subprocess and simply let PlantUML deal with the preprocessing logic. That's probably preferable, but will not work when you want to use a real diagram server. @Mogztter does asciidoctor-kroki handle this case?

[aowss]

@pepijnve has this been fixed in any way ( re-implement or pass the directory ) ?

[pepijnve]

For #343 I implemented the logic to delegate all include processing to PlantUML itself. The correct base dir should be getting passed to the preprocessor. That change was included in v2.1.1. If this isn't working for you please open a new issue.