Another tables rendering bug

[MOZGIII]

This code does not work right:

@startuml
state X {
  state Y
}
X: |= header 1 |= header 2 |= header 3 |
X: | //A// | abc | def |
X: | //B// | qwe | |
@enduml

At the same time, without inner state it works:

@startuml
state X {
}
X: |= header 1 |= header 2 |= header 3 |
X: | //A// | abc | def |
X: | //B// | qwe | |
@enduml

Could you please fix the first case?

[arnaudroques]

This one is one our side : we're going to have a look on this

[arnaudroques]

Thanks for the feedback. This should be ok in last beta: https://www.dropbox.com/s/koo42q3d9gxw288/plantuml.jar?dl=0

[MOZGIII]

Great, I'll try it tomorrow.

[MOZGIII]

With this version I have different errors in many of my diagrams, preventing them from building at all. A simple test with table and states in a state works though.

[MOZGIII]

Well, there we really not much errors. However, another problem is introduced: in a component diagram I have a set of macros, which sometimes end up in rendering the same interfaces twice (exact same definition but multiple times, depending on what is needed to be generated). It used to work ok, but now it fails with error saying This element (ElementNameHere) is already defined. This breaks my logic on code organizing. Maybe there is some other way to do what I want, but I'm not familiar with it.

[arnaudroques]

We've made some modification recently to be more strict on redefining elements (see http://plantuml.sourceforge.net/qa/?qa=5760/error-message-if-same-name-is-used-for-different-objects ) But probably we've been too strict here, so we will allow to have interfaces and classes to be defined multiple times.

[MOZGIII]

Oh, I think that change is great, however it should block usage of the same name for different object. If objects are exactly the same, there should be no problem at all with allowing this behavior. My workflow would benefit from this too, as it would allow less silent mistakes, while the whole approach would work.

[arnaudroques]

Should be fixed https://www.dropbox.com/s/koo42q3d9gxw288/plantuml.jar?dl=0

[aadrian]

@arnaudroques sorry but why binary in Dropbox? Why don't just just configure PlantUML to publish to Sonatype Snapshots all the time, so that it's built all the time, so you just commit (to github)?

[prost3tnik]

it's the lone "x" ("x1" is good):

@startuml
namespace X.y {  
}
hide X.y
@enduml

cat test.txt | java -jar plantuml.jar -syntax
CLASS
(2 entities)

@startuml
namespace A.y {  
}
hide A.y
@enduml

(0 entities)

using the current version from plantuml.org:

java -jar plantuml.jar -version
PlantUML version 1.2018.01 (Sun Jan 28 19:08:22 CET 2018)

an even more simple example. this one should error:

@startuml
hide X.y
@enduml

instead it produces two classes

maybe just document it? oh, and add @startuml/ @enduml tags to .iuml example on the preprocessing page.