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...