Text on arrows not working if in !include

Question

I have an activity diagram I want to include in other activity diagrams.

        @startuml(id=mobile-bankd-end-split)         

          split
          ->Mobile;
          (Z)
          Detach
          splitagain
          ->Bank;
          stop
          endsplit

        @enduml

When included in other diagrams, the arrow text is not rendered correctly.

If arrow text is used in the main diagram (not an included diagram), the text renders correctly.

Is this a bug?

Answer 1

It sounds like a bug. However, it would be nice if you could show us the bug.

Please post here the shortest example that shows the issue.

Thanks!

Comments

The component diagram that I want to include in other diagrams:

@startuml(id=mobile-bank-end-split)         

          split
          ->Mobile;
          (Z)
          Detach
          splitagain
          ->Bank;
          stop
          endsplit

        @enduml

The diagram in which I want to include the component diagram:

                      @startuml
          :Present Reset\nPassword Page;
          if (Password Reset\nSuccess?) then (Yes)
          (X)
          Detach
          (X)
          :Login Page with\nSuccess Message;
          !include_many p_Forgot-Password-ID.xml!mobile-bank-end-split
          else (No)
          (Y)
          Detach
          (Y)
          :Login Page with\nGeneric Error Message;
          !include_many p_Forgot-Password-ID.xml!mobile-bank-end-split
          endif
          @enduml

The file p_Forgot-Password-ID.xml contains both diagrams. 

---

Which version of PlantUML are you using ? You can double-check it with:

@startuml
version
@enduml

We've just tested your example, and the arrow are printed.

---

PlantUML version 1.2019.08

We are using the Oxygen XML plugin to the DITA Open Toolkit.
https://github.com/oxygenxml/dita-plant-uml

I also notice that Graphviz is not installed on our delivery server. Would that have anything to do with it? We are using the beta activity diagrams only. 

---

GraphViz is not needed for beta activity diagrams.

Maybe it's related to PlantUML version beeing old.

Could you try the full diagram :

@startuml
:Present Reset\nPassword Page;
if (Password Reset\nSuccess?) then (Yes)
(X)
Detach
(X)
:Login Page with\nSuccess Message;
split
->Mobile;
(Z)
Detach
splitagain
->Bank;
stop
endsplit
else (No)
(Y)
Detach
(Y)
:Login Page with\nGeneric Error Message;
split
->Mobile;
(Z)
Detach
splitagain
->Bank;
stop
endsplit
endif
@enduml

Another option may be the starting "->" that may confuse Oxygen plugin (?)

---

The full diagram shows the arrows and text as expected. It is only on an included diagram that the text is not correct on the arrow.

I'll follow up with the developers of the Oxygen plugin.

Thank you for your prompt responses.

---

The problem with the XSLT plugin which uses PlantUML to convert to SVG is that a pre-processing stage takes the included file and converts in it the ">" to ">".

Besides setting this system property:

     java.lang.System.setProperty("plantuml.include.path", ...);

is there extra API available which would allow me to programatically control from the Java side the content retrieved for each reference?

Some kind of "Resolver" API:

   InputStream resolveReference(String reference)

which would allow me to pre-process the contents, convert the > to > and then return an input stream to PlantUML?

---

(...)InputStream resolveReference(String refference)

Unfortunately, it's not possible.

It seems to us that the bug is really on the XSLT plugin, and not on PlantUML library side.

However, we would like to help you :-)

So we've build a new beta http://beta.plantuml.net/plantuml.jar which convert > to > when reading files. This is really a temporary solution, just to check that it solves your issue.

If it does solve your issue, we will implement something better, with a setting that will allow you to enable/disable this > to > conversion.

So tell us if it works better with the beta. Thanks!

---

The beta library works. But a fix like you did is not really scalable.This is not a bug either in PlantUML or in the XSLT processing, it's more of a problem of getting two formats which are a little bit incompatible to work with each other..

As an example, of the problem let's say we have a file called "text.xml" with the contents:

<root>
        @startuml(id=olb-mobile-end-split)
        split
        -&gt;Mobile&#59;
        (Z)
        Detach
        splitagain
        ->Online Banking;
        stop
        endsplit
        @enduml
</root>

This "root.xml" is referenced in another PlantUML diagram like:

!include_many text.xml!olb-mobile-end-split

So your code ends up loading the "text.xml", you convert &gt; to ">" with the current fix but with XML you could use also entities like &lt; or &#59; (used also in the sample above) to express various characters so your code would need to also convert these entity references to characters.

In a way I don't think your code should be responsible for doing this, this is why I would have preferred some Java API which would allow my code to pre-process the contents in the "text.xml" before they are read by your code, some API in which you ask the input stream from a certain API interface and it can give you a modified input stream which converts XML entity references to plain characters.

---

The beta library works. But a fix like you did is not really scalable.

Yes, you're right. I better understand the issue now.

As an example, of the problem let's say we have a file called "text.xml" with the contents:
<root>
        @startuml(id=olb-mobile-end-split)
        split
        -&gt;Mobile&#59;
        (Z)
        Detach
        splitagain
        ->Online Banking;
        stop
        endsplit
        @enduml
</root>

This file cannot indeed be included as-is by PlantUML.
A solution would be to pre-process this "text.xml" file using awk/sed/grep to generate a "text.iuml" file. "text.iuml" would be corrected formatted.

So now you could !include this file:

!include_many text.iuml!olb-mobile-end-split

To me, there is no need to have a Java API to do such a pre-process.
What do you think about it ?

---

I agree this could be handled outside the PlantUML library. Using the API I could have dynamically pre-processed the file contents as it was accessed by PlantUML but the API is not necessary.

Thanks for the prompt responses.