plantuml.jarArgs only works with absolute path

[dg-skolberg]

Hi,

many thanks for this great plugin.

However, I seem to be unable to get my project specific plantuml.config into the plugins preview renderer without using an absolute path.

The example says I should use { "settings": { "plantuml.jarArgs":[ "-config", "plantuml.config" ] } }

But where should the file then be located?

I tried

• copying the file to the workspace root
• copying the file to the diagram source folder

and some even more obscure paths. But all I get is a PathNotFoundException

Error found in diagram Firmware Update
Exception in thread "main" java.io.FileNotFoundException: plantuml.config (No such file or directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at java.io.FileInputStream.(FileInputStream.java:93)
at java.io.FileReader.(FileReader.java:58)
at net.sourceforge.plantuml.Option.initConfig(Option.java:367)
at net.sourceforge.plantuml.Option.(Option.java:220)
at net.sourceforge.plantuml.Run.main(Run.java:79)

Might this be related to this comment?

Ultimately, I think, it would be nice, if we could use ${workspaceFolder} in workspace settings as well as the within plantuml config file itself to reference includes within the projects directory structure.

!include ${workspaceFolder}/includes/macros.wsd
!include ${workspaceFolder}/includes/skinparams.wsd

[qjebbs]

In fact, you can simply use:

!include includes/macros.wsd
!include includes/skinparams.wsd

the extension just passes your args to plantuml.jar, your problem is about how the plantuml.jar process the args, not the extension.

[dg-skolberg]

Thanks a lot for the quick reply :)

In fact, you can simply use:

!include includes/macros.wsd
!include includes/skinparams.wsd

the extension just passes your args to plantuml.jar, your problem is about how the plantuml.jar process the args, not the extension.

Hmm, that does not seem to work for me.

When I trie, I get yet another FileNotFoundException indicating that the include files were searched in a path relative to the diagram location <workspace root>/<path-to-diagram>/./includes/macros.wsd instead of <workspace root>/includes/macros.wsd.

BUT, first things first:

My original problem is with workspace configuration to execute plantuml.jar with -config plantuml.config. Sorry for mixing 2 different issues in one.

When I execute plantuml.jar directly from workspace root:

java -jar ~/.vscode/extensions/jebbs.plantuml-2.9.2/plantuml.jar -config plantuml.config /path/to/diagram

with plantuml.config lying in that same workspace root, it works as expected.

And this is how I would have expected the plugin to work for preview rendering. But that is obviously not the case. Hence the FileNotFoundException described in the issue.

Here is my complete workspace config:

{
	"folders":[
		{ "path":"." }
	], 
	"settings": {
		"plantuml.includes":["includes"], 
		"plantuml.jarArgs":[
			"-config", "plantuml.config"
		]
	}
}

I believe it is pretty straight forward, plantuml diagrams is all I do in this workspace.

[dg-skolberg]

BTW, I am working on macOS

[qjebbs]

Yes, it's better to search include files in diagrams root (default, it is the workspace root), fixed path.

[dg-skolberg]

Hi again, I appreciate the quick fix.

However, I have experimented a bit plantuml.jar on the command line and wanted to give you the additional information.

From my experiments it seems that plantuml.jar does not take -Duser.dir into account when resolving -config plantuml.config.

# plantuml.config is located in '~/development/local/diagrams/sources'
# calling the jar from diagram dir '~/development/local/diagrams/sources/diagramDir'
08:09:32 {master *=} ~/development/local/diagrams/sources/diagramDir$ java -jar -Duser.dir=/Users/Kolberg/development/local/diagrams ~/.vscode/extensions/jebbs.plantuml-2.9.4/plantuml.jar -config sources/plantuml.config sources/diagramDir/SomeAwesomeStateMachine.puml

# yields FileNotFoundException, see the path in the exception.
Exception in thread "main" java.io.FileNotFoundException: sources/plantuml.config (No such file or directory)
        at java.io.FileInputStream.open0(Native Method)
        at java.io.FileInputStream.open(FileInputStream.java:195)
        at java.io.FileInputStream.<init>(FileInputStream.java:138)
        at java.io.FileInputStream.<init>(FileInputStream.java:93)
        at java.io.FileReader.<init>(FileReader.java:58)
        at net.sourceforge.plantuml.Option.initConfig(Option.java:367)
        at net.sourceforge.plantuml.Option.<init>(Option.java:220)
        at net.sourceforge.plantuml.Run.main(Run.java:79)

Now, as a negative check I tried the same command line without the -config argument.

08:09:38 {master *=} ~/development/local/diagrams/sources/BPC$ java -jar -Duser.dir=/Users/Kolberg/development/local/diagrams ~/.vscode/extensions/jebbs.plantuml-2.9.4/plantuml.jar sources/diagramDir/SomeAwesomeStateMachine.puml
0

Imo, this is a bug in plantuml itself, so I already posted a Bug/Question for plantuml here.

However, I'd also like to mention that an automatic 'plantuml.config' (by naming convention) search by the plugin looking in the following directories (in order):

• diagram dir
• diagrams.root
• workspace.root
• (maybe even) user.home

might be worth considering.

[qjebbs]

Since the setting is named as jarArgs, they are processed by plantuml.jar. Except the CWD, anything I do is excess, even dangerous (to other args other than -config). It's better plantuml.jar could implement these logic.

[qjebbs]

An alternative practice for your use case would be,

If you want to include a config file for all diagrams, all projects:
Put the file in user.home, and set the global setting, referencing the file with absolute path

If you want to include config file different for each project:
Put the file in diagramsRoot, and set the workspace setting, referencing the file with relative path

PS: I'll change the jarArgs scope to resource, so that you can have different setting between projects.

[qjebbs]

According to my test, the current plantuml.jar works as expected:

A project:

Project Folder/
  docs/
    src/
      inc.iuml
      file1.wsd
    out/
      file1.png

with following workspace settings:

{
    "plantuml.diagramsRoot": "docs/src",
    "plantuml.exportOutDir": "docs/out",
    "plantuml.jarArgs": [
        "-config",
        "inc.iuml"
    ]
}

Every file will include the inc.iuml

PS: The extension set both the user.dir and process CWD, I don't sure if the jar ignores the user.dir, but it will work it takes one of them.

[qjebbs]

You can now test above setting with v2.9.6, please update.

[c-hoeger]

Unfortunately after installing the version containing these changes, I am no longer able to use the preview.

I have the following layout:

toplevelfolder/
  Intro.uml
  subfolder1/
      sequence1.uml
         !include ../Intro.uml
  subfolder2/
      sequence1.uml
         !include ../Intro.uml

Now I get the error message:

Cannot include /Users/.../toplevelfolder/./../Intro.uml

So the path it is looking up is now is wrong. Should be:

/Users/.../toplevelfolder/subfolder1/../Intro.uml

Running plantuml on the commandline still works as expected. Any idea how to solve this?

[qjebbs]

@c-hoeger Now you can use !include Intro.uml to all workspace files, no matter where it is.

[c-hoeger]

Now you can use !include Intro.uml to all workspace files, no matter where it is.

The situation here is not that easy, unfortunately. There are some external automation scripts running on the same directory layout and when I break this path, they won't find the included files anymore. I really don't understand what is wrong in specifying the correct relative path to the included file(s). I am now using version 2.9.2 from your extension which works like it IMO should.

[qjebbs]

@c-hoeger see #158 (comment)

[c-hoeger]

Excellent, thanks!

[dg-skolberg]

Hi again,

my question here brought to light that there is a bug in the plantuml version used by the plugin (if you have not updated it yet).

After replacing the integrated plantuml.jar with version 1.2018.11 user.dir is processed by plantuml as expected and everything works as it should.

No more absolute paths anywhere, only paths relative to diagrams.root.

Cheers
Sascha

[qjebbs]

Relative to diagramsRoot should also work to old version of plantuml.jar too..

[nsainaney]

This issue seems to have regressed in v2.15.1. I'm only referring to the Preview

The following settings.json works:

{
    "plantuml.jarArgs": [
        "-config",
        "/<full-path-to-workspace>/plantuml.iuml"
    ]
}

but

{
    "plantuml.jarArgs": [
        "-config",
        "plantuml.iuml"
    ]
}

results in

Error found in diagram halyard-decomp
Exception in thread "main" java.io.FileNotFoundException: plantuml.iuml (No such file or directory)
at java.base/java.io.FileInputStream.open0(Native Method)
at java.base/java.io.FileInputStream.open(FileInputStream.java:213)
at java.base/java.io.FileInputStream.(FileInputStream.java:155)
at java.base/java.io.FileInputStream.(FileInputStream.java:110)
at java.base/java.io.FileReader.(FileReader.java:60)
at net.sourceforge.plantuml.Option.initConfig(Option.java:436)
at net.sourceforge.plantuml.Option.(Option.java:244)
at net.sourceforge.plantuml.Run.main(Run.java:87)

[nsainaney]

Please disregard the above - oddly enough, restarting VSCode and re-installing the plugin seemed to have solved the issue