Duplicate package names will affect the diagram

[yapinxxx]

I think this is a bug.

Different packages should have different paths.

We could use a hash checksum to distinguish between packages with the same name or add the upper-level folder name to the namespace until the paths are different.

Otherwise, it will create an incorrect UML diagram.

[githoober]

Is this what's happening right now?

[ryo-arima]

Hello!
I just started using this great tool a short while ago.

I am developing a tool like this,
https://github.com/ryo-arima/mark1

I think the UML is being output as the same package, when in fact it is a different package, because the package names under client and server are the same. However, it is possible that my design is bad.....
I am checking the details now.

This is the command I executed.

$ goplantuml -show-aggregations -recursive pkg/ > {path}/{filename}.plantuml

<Sample of output＞
plantuml: https://gist.github.com/ryo-arima/b46ae172e295441e6be96397e083edfb
image: https://github.com/user-attachments/assets/16657449-8015-4a5d-a84d-aa65930cb07c

Sorry if this is a different topic....

[yapinxxx]

Hello! I just started using this great tool a short while ago.

I am developing a tool like this, https://github.com/ryo-arima/mark1

I think the UML is being output as the same package, when in fact it is a different package, because the package names under client and server are the same. However, it is possible that my design is bad..... I am checking the details now.

This is the command I executed.

$ goplantuml -show-aggregations -recursive pkg/ > {path}/{filename}.plantuml

<Sample of output＞ plantuml: https://gist.github.com/ryo-arima/b46ae172e295441e6be96397e083edfb image: https://github.com/user-attachments/assets/16657449-8015-4a5d-a84d-aa65930cb07c

Sorry if this is a different topic....

Thanks for your reply!

I think you're encountering the same issue as I did. I don't believe this structure design is inherently bad, as it follows the Golang package architecture. However, when we have more packages and use short names, this problem inevitably arises.

In my case, when my system has multiple different services with packages named "server," the UML creates incorrect relationship diagrams.

[yapinxxx]

Is this what's happening right now?

Unfortunately, I think this issue is still occurring. I just tested it on my project, and it caused the same problem.
I have two sub-packages with the same name, and both contain a struct with the same name.

This leads to an ambiguity in the graph, where the two different structs are merged into one nonexistent struct.

[ryo-arima]

Thanks for your reply!

I think you're encountering the same issue as I did. I don't believe this structure design is inherently bad, as it follows the Golang package architecture. However, when we have more packages and use short names, this problem inevitably arises.

In my case, when my system has multiple different services with packages named "server," the UML creates incorrect relationship diagrams.

Thank you for your reply too!

Yes, I think it is.
I think the GO naming convention favors short and simple names, so I too think it is fine as it is.

However, in larger implementations, I think there is room for improvement, as care must be taken when using goplantuml.

For example, “pkg/server/controller” is identified as “pkg.server.controller” and display.
pkg/client/controller” should be identified as ‘pkg.client.controller’ and display.
But I think there are various ways of displaying...

[jfeliu007]

I am not sure if the lates update v1.6.3 I just introduced will fix this issue, I added support for nested packages and it is possible these will be rendered better now.

[yapinxxx]

I am not sure if the lates update v1.6.3 I just introduced will fix this issue, I added support for nested packages and it is possible these will be rendered better now.

Thank you your response @jfeliu007

I’m very happy to hear this information! I’ll try to use the latest version in the coming days.

[ryo-arima]

@jfeliu007
Thank you for the improvements and notification!

I tried generating the diagram again.
The structure generation output was as expected!

However, the interface and function output seems slightly different from what I imagined...
Is this the intended behavior? (Is the sample bad?)

target project
https://github.com/ryo-arima/mark1

This is the command I executed.

$ goplantuml -show-aggregations -recursive pkg/ > {path}/{filename}.plantuml

output svg
https://github.com/user-attachments/assets/e3557c0b-cf43-454e-9d72-1c4edd5dcba7
output puml
https://gist.github.com/ryo-arima/a6681e8a669b6cf5f1e0688a857f6307